pg has asked for the wisdom of the Perl Monks concerning the following question:

I started recently to use HTTP::Daemon for my web server, but occassionaly (actually quite often) it fails to handle multiple requests with one connection. I was calling get_request method of that package, from time to time, the client site (browser) just hangs.

The code is something like (as suggested in its doc)
while ($connection->get_request) { #hanles the req here }

The problem could be easily fixed by closing the socket after handling each request. This simply tells the client that, sorry I don't handle multiple request with one connection, please send next request again with a new connection.

This works fine as it should be, but there are questions left over...

Is this a known problem with HTTP:Daemon (it works sometime, but not stable at all in terms of multi-request-with-one-connection.) or just that I missed something

What do you guys usually do to fix this?

Replies are listed 'Best First'.
Re: HTTP::Daemon cannot support keep alive properly?
by vek (Prior) on Oct 11, 2003 at 20:41 UTC

    In order to handle multiple concurrent requests, you'll have to fork a new process. HTTP::Daemon does not do this for you. From the doc:

    This HTTP daemon does not fork(2) for you. Your application, i.e. the +user of the HTTP::Daemon is reponsible for forking if that is desirab +le.

    You'll need to add something like this (untested):

    my $d = HTTP::Daemon->new || die; while (my $c = $d->accept) { my $childPID; unless (defined $childPID = fork) { # error handling here... next; } if ($childPID == 0) { # we're the child, # your processing code here... } # we're the parent, go back and wait # for another request... }

    That should give you an idea of what you'll need to do.

    UPDATE - Disregard - I had the wrong end of the stick entirely :-)

    -- vek --

      Thanks vek, but you mis-interpreted the issue, and what you said is not the point here.

      I knew that, to process multiple connections AT THE SAME, I need to fork or using multi-thread, and that's what I did.

      The problem here is a different turkey (is it because Thanksgiving is coming? ;-). HTTP/1.1 allows the client (usually a browser) to send multiple HTTP requests over the same connection (this is called keep alive), and they comes obviously in sequence as those are from the same client (unless the client does multi-threading, but even this is the case, it is still not a problem). On the server site, there is no need for multi-threading for this PARTICULAR issue, especially when you sepcify socket queue size greater than 1 for example 20 something. Even if the requests over the same connection come in at the same time, they will just be queued, ready for being processed later, and no harm is done.

      But thanks for your idea any way, have a great day.

Re: HTTP::Daemon cannot support keep alive properly?
by dws (Chancellor) on Oct 12, 2003 at 15:26 UTC
    With the caveat that this is based on dim memory, I futzed around with HTTP::Daemon a few years back, and recall that getting Connection: keep-alive working took a combination of

    1. making sure that sockets were unbuffered, and
    2. generating an accurate Content-length: header.

    But, unless you can fork, or otherwise multiplex I/O, you're liable to see strange browser behavior, since most browsers (or at least IE, since the early days) try to use two sockets at once to optimize page and image transfer. You also have to worry about the cause of a browser asking to keep a connection alive, and then, for whatever reason, not using it again.

    I think what I ended up doing was to punt on http-alive, and fall back to HTTP 1.0 behavior. It was good enough for what I was doing at the time (which was putting a custom, low-bandwidth web server up on a machine that I didn't have administrative access to).

Re: HTTP::Daemon cannot support keep alive properly?
by Anonymous Monk on Oct 12, 2003 at 10:44 UTC
    What do you guys usually do to fix this?
    Analyse the situation and identify the problem, then fix it.