On Fri, Jun 21, 2002 at 04:02:52PM -0400, Greg Ames wrote:
> Justin Erenkrantz wrote:
>
> > Only where ap_status_drops_connection is true. The problem before
> > was that if you got a 404 and then got a 413 on the discard, it
> > would revert the status to a 404 and then try to read the body as
> > part of the handlers in serving the error page.
> >
> > We simply can not do that - so the status can't be 404 when we get a
> > 413 - it must be a 413. When we are supposed to drop the connection,
> > r->status *must* indicate that.
>
> OK, let's turn that around. Suppose we got a 413 first and then a 404. Which
> one should we believe? And how should our canned error message read in both
> cases?
The 413. I don't believe we have to tell them that we screwed up in
getting a 404 to the error page (I dislike the whole recursive error
thing anyway). IMHO, it doesn't add anything of value.
> We ought to be able to display both in the correct order in our canned error
> message, no matter which happens first. And it sounds like if *either* status
> wants to drop the connection, we should avoid reading the body. Since ap_die
> now resets r->connection->keepalive anytime ap_status_drops_connection is true
> for the input status, I think this change to
> ap_discard_request_body would work:
>
> --- modules/http/http_protocol.c 19 Jun 2002 18:43:28 -0000 1.440
> +++ modules/http/http_protocol.c 21 Jun 2002 19:41:00 -0000
> @@ -1882,7 +1882,7 @@
> *
> * This function is also a no-op on a subrequest.
> */
> - if (r->main || ap_status_drops_connection(r->status)) {
> + if (r->main || !r->connection->keepalive) {
> return OK;
> }
Hmm. I'm not sure if I like that or not. What if ap_die isn't
involved and the status is set to drop the connection? Perhaps
we could just add the closing of the socket as another
condition? -- justin
