Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (herse.apache.org: local policy)
From: Jim Jagielski <jim@jaguNET.com>
Message-Id: <200611281809.kASI9lB06280@devsys.jaguNET.com>
Subject: Re: svn commit: r480135 -
 /httpd/httpd/trunk/modules/http/http_filters.c
To: dev@httpd.apache.org
Date: Tue, 28 Nov 2006 13:09:44 -0500 (EST)
Reply-To: jim@jaguNET.com
In-Reply-To: <20061128180508.GC17309@redhat.com> from "Joe Orton" at Nov 28,
 2006 06:05:09 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Joe Orton wrote:
> 
> On Tue, Nov 28, 2006 at 05:36:55PM -0000, Jim Jagielski wrote:
> > Author: jim
> > Date: Tue Nov 28 09:36:45 2006
> > New Revision: 480135
> > 
> > URL: http://svn.apache.org/viewvc?view=rev&rev=480135
> > Log:
> > Apply patch for PR 41056 (19954) to fix chunk
> > filter. Now flushes work better.
> 
> This looks wrong to me.  When reading the CRLF in state == BODY_CHUNK 
> with block == _NONBLOCK, the initial ap_get_brigade() may return EAGAIN, 
> and then the code will fall into the generic error handling branch:
> 
>                 /* Detect chunksize error (such as overflow) */
>                 if (rv != APR_SUCCESS || ctx->remaining < 0) {
> 
> The API use is weird too.  This code presumes that the next filter 
> indicates read-would-block only by returning SUCCESS with an empty 
> brigade.  Yet it signals the same thing to the downstream filter only by 
> failing with EAGAIN!
> 

My intent was, as long as it passes the test-framework (and it does),
to take advantage of CTR and not let this patch not get a
look over... I agree that it's not complete yet and I've only
done a cursory look at it myself to be honest with you. :)

-- 
===========================================================================
   Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
	    "If you can dodge a wrench, you can dodge a ball."