in reply to Check if a scalar contains a complete HTTP request

Instead of doing this myself, I would look at one of the asynchronous frameworks, which all can handle that.

See threads, AnyEvent, Mojolicious and IO::Async. There likely are more, but I boldly assume that all of them handle HTTP requests incoming and outgoing.

If you have too much code written for your custom socket to rewrite for another framework, then running the HTTP part in a thread or separate process might be an approach that gives you only complete requests that can be read blocking.

  • Comment on Re: Check if a scalar contains a complete HTTP request

Replies are listed 'Best First'.
Re^2: Check if a scalar contains a complete HTTP request
by FloydATC (Deacon) on May 20, 2017 at 11:02 UTC

    Handling of the non-blocking sockets is not the issue, data from each client already flows beautifully into buffers thanks to IO::Select/sysread/syswrite and that bit works like a charm. It's just that I have about 60-70 lines of code just to grab HTTP requests from those buffers and besides being an eyesore I'm pretty sure it will fall over pretty soon if exposed to the real world.

    The main loop for each client/server socket pair kind of goes like this:
    1. Read from sockets that can be read from
    2. Fill inspection buffer with data from client
    3. If a buffer has been modified, see if it contains a HTTP request, complete with content (possibly chunked)
    4. If a HTTP request was found, remove it from the inspection buffer and allow/deny it
    5. Write allowed data to sockets that can be written to

    This is for SSL inspection if you didn't already guess, the prototype works but I'm trying to make it more robust.

    -- FloydATC

    I got 99 problems, most of them have to do with printers.

[reply]
      I guess I'm a bit lost here because this looks like the wrong application for a select server. Why aren't you using a normal TCP client/server model? What does this have to do with SSL inspection? Just curious..
[reply]

        Short answer: Because traffic over tcp/443 can be a lot more than just HTTP request/response transactions that follow a predictable pattern, and it's the non-HTTP traffic that really interests me. This means I have to quickly and reliably filter out the actual HTTP traffic.

        -- FloydATC

        I got 99 problems, most of them have to do with printers.

[reply]

In Section Seekers of Perl Wisdom