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:45:06 GMT
On Sun, 9 Feb 1997, Marc Slemko wrote:

> > 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. [...]
> Yup, I thought of that soon after I sent it.  Can't you just limit it to
> GETs?

Sure, I suppose.

> > 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).
> That's silly.  Could just remove the content-length from headers_out or
> modify set_keepalive() to take the headers as a param...

Yes, you could.

> > 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.
> Hmm.  Interesting.  Could, of course, be disabled for them.  Shouldn't be
> much trouble to make them work.

Actually, since custom error messages are enabled as an internal
redirect, I imagine that they use keepalive now. Which is a problem
with the POST/PUT thing I mentioned earlier. As I said, this should be
looked into.

> > There are at least those three issues. There maybe more.
> Probably.  Too bad this wasn't worked on harder earlier; would have been
> nice to have in 1.2.  Ah well.

As you point out, the problems I mentioned are not all that hard to
surmount, it's just that there are a number of them, and probably
more. It's why I never did persistant connections for error messages
back in 1.1.

Alexei Kosut <>      The Apache HTTP Server

View raw message