httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: [PATCH] why not keepalives on errors?
Date Sun, 09 Feb 1997 07:06:05 GMT
On Sat, 8 Feb 1997, Marc Slemko wrote:

> Does the below patch miss something?  'twould be nice to do persistent
> connections (even though they will only work for 1.1 clients...) for
> things like redirects, etc.

In short, yes (I explained all this in a message directed at Dean a
week or so ago...):

1. POST/PUT requests. If the error comes before the module has read in
   the request entity, and the server keeps the connection open, it
   will be treated as the next request (since it'll be in the input
   stream), and chaos will ensue. Unfortunately, the server has no
   clue whether or not the error was sent before or after the entity
   was read (mod_cgi returns errors both before and after, for
   example). This needs, at the least, a lot of thought and
   modification of the *_client_block() functions, as well as new
   code in the error handling routines.

2. set_keepalive() is designed for a normal request. So it checks
   r->headers_out for Content-length. Note, though, that there could
   be a content length set, but it would be wrong, since we are now
   dealing with an error message. set_keepalive() will then try and
   use non-chunked keepalive, and will send the headers such. Oops.
   Note that this will happen with a core-handled file if read
   permissions are not correct (default_handler() tries to set content
   length before it tries to open the file).

3. Three words: custom error messages. Honestly, I don't know how this
   patch would interact with those. For that matter, I don't know how
   keepalives work with this *now*. I should probably look into it.

There are at least those three issues. There maybe more.

Alexei Kosut <>      The Apache HTTP Server

View raw message