Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: Pre-release test tarballs of httpd 1.3.40,
 2.0.62 and 2.2.7 available
Date: Wed, 9 Jan 2008 11:15:57 +0100
Message-ID: 
 <99EA83DCDE961346AFA9B5EC33FEC08B05B2E6@VF-MBX11.internal.vodafone.com>
In-Reply-To: <20080109002717.3bc4bc9e@grimnir>
Thread-Topic: Re: Pre-release test tarballs of httpd 1.3.40,
 2.0.62 and 2.2.7 available
Thread-Index: AchSVn4SHjcVUjPLQGClJ1p+5z6KtQAUOv3w
From: =?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VF-Group?=
 <ruediger.pluem@vodafone.com>
To: <dev@httpd.apache.org>


> -----Urspr=FCngliche Nachricht-----
> Von: Nick Kew=20
> Gesendet: Mittwoch, 9. Januar 2008 01:27
> An: dev@httpd.apache.org
> Betreff: Re: Pre-release test tarballs of httpd 1.3.40,=20
> 2.0.62 and 2.2.7 available
>=20
>=20
> On Mon, 07 Jan 2008 11:29:43 +0100
> Ruediger Pluem <rpluem@apache.org> wrote:
>=20
> > I will also propose the optimizations. If someone has cycles to
> > review then fine, if not then in 2.2.9 :-).
>=20
> At lines 364 and 460 (trunk), you set HTTP_SERVICE_UNAVAILABLE
> when broken chunking is encountered.  I don't think that's right:

That's because this was the error code that was used there before for
empty chunk size lines, but I agree that this error code might be wrong.

>=20
> - bad chunking in a request should return HTTP_BAD_REQUEST
> - bad chunking in a proxy response should return HTTP_BAD_GATEWAY
>=20
> Can we know if we're processing request or response at this point?

IMHO unfortunately not, but it does not matter in the proxy case anyway,
because the error messages sent via bail_out_on_error are sent to the =
backend
server in this case and not the client :-). This is because we have =
switched
the meaning of INPUT and OUTPUT filters for our proxy connection to the =
backend.
The client will receive internal server error just as with your test =
with the
insane sized chunk extension. This is no regression it has worked =
forever like this.
So in the light of this it might make sense to change this simply from
HTTP_SERVICE_UNAVAILABLE to HTTP_BAD_REQUEST. WDYT?

>=20
> Also, I committed a simple edge-case fix against empty data
> buckets getting in the way of detecting a lineend.
> I presume you're OK with r610240?

Thanks. Your patch is much better than my stupid one.

Regards

R=FCdiger