httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: httpd-2.0 STATUS
Date Mon, 17 Sep 2001 13:16:13 GMT
This is an ugly bug.

* open a connection to apache. toss in 100 GET requests. no problem.

* try the same, but with "hello" in the body of the GET request. Apache
  closes the connection after sending back the first response.

Of course, substitute your favorite POST, PUT, PROPFIND, or whatever other
method that contains a body. Bam! Apache is gonna close the connection.

"wtf?" you say... Well, I tracked it down to a problem with the HTTP_IN
filter and its call to apr_brigade_split() on line 690. The new, returned
brigade is created in the same pool as "b" -- that pool is the request pool.
Thus, at the end of the request ctx->b is cleared out, and on the next entry
to the HTTP_IN filter (read_request_line for the next request), it tries to
refill ctx->b with data. CORE_IN punts with APR_EOF, so the request logic
thinks "done. let's shut down."

There are a few band-aid solutions to the problem:
1) ctx->b->p = f->c->pool  (and somehow tweak the cleanups)
2) copy the returned brigade into a properly-allocated brigade
3) pass a pool to apr_brigade_split() for the new brigade

IMO, the right answer is to fix up the input processing so we don't even
have to do all of that splitting and brigade munging.
(otherwise, (3) is the better of the above options)

Cheers,
-g

On Mon, Sep 17, 2001 at 11:22:53AM -0000, gstein@apache.org wrote:
> gstein      01/09/17 04:22:53
> 
>   Modified:    .        STATUS
>   Log:
>   Found the persistent connection problem I've been observing. Nasty result of
>   the problems in the input filter stack. Time to rejigger, per the
>   discussions we've had.
>   
>   Revision  Changes    Path
>   1.296     +24 -1     httpd-2.0/STATUS
>   
>   Index: STATUS
>   ===================================================================
>   RCS file: /home/cvs/httpd-2.0/STATUS,v
>   retrieving revision 1.295
>   retrieving revision 1.296
>   diff -u -r1.295 -r1.296
>   --- STATUS	2001/09/17 02:33:40	1.295
>   +++ STATUS	2001/09/17 11:22:52	1.296
>   @@ -1,5 +1,5 @@
>    APACHE 2.0 STATUS:						-*-text-*-
>   -Last modified at [$Date: 2001/09/17 02:33:40 $]
>   +Last modified at [$Date: 2001/09/17 11:22:52 $]
>    
>    Release:
>    
>   @@ -107,6 +107,29 @@
>    
>            This builds mod_headers as a DSO (good) but builds mod_mime
>            as a compiled-in module (bad).
>   +
>   +    * revamp the input filter semantics, per discussions since
>   +      February (and especially at the hackathon last
>   +      April). Specifically, ap_get_brigade will return a brigade with
>   +      *up to* a specific number of bytes, or a "line" of data. The
>   +      read may be blocking or nonblocking. ap_getline() will be
>   +      refactored into apr_brigade_getline(), and then DECHUNK can use
>   +      f->next (ap_getline will always read "top of input stack"). Also 
>   +      fix the bug where request body content will end up closing the
>   +      connection (buggering up persistent conns).
>   +
>   +      - socket bucket and core input filter changes. see end of
>   +        message ID (Feb 27): <20010227075326.S2297@lyra.org>
>   +
>   +      - fix up ap_get_brigade() semantics, fix bug in DECHUNK /
>   +        ap_getline. many messages (plus their threads) (Apr/May):
>   +          Message-ID: <20010402101207.J27539@lyra.org>
>   +          Message-ID: <3AF7F921.D2EEC41A@algroup.co.uk>
>   +          Message-ID: <20010508190029.E18404@lyra.org>
>   +
>   +      - further work with combining/tweaking the builtin filters:
>   +          Message-ID: <20010509115445.D1374@lyra.org>
>   +
>    
>    RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
>    
>   
>   
>   

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message