httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Re: cvs commit: httpd-2.0/modules/http http_request.c
Date Fri, 21 Jun 2002 21:21:19 GMT
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

Mime
View raw message