Date: Sat, 8 Feb 1997 23:45:06 -0800 (PST)
From: Alexei Kosut <akosut@nueva.pvt.k12.ca.us>
To: new-httpd@hyperreal.com
Subject: Re: [PATCH] why not keepalives on errors?
In-Reply-To: <Pine.BSF.3.95.970209002044.3343V-100000@alive.ampr.ab.ca>
Message-Id: <Pine.HPP.3.95.970208234315.24799A-100000@ace.nueva.pvt.k12.ca.us>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

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 <akosut@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/