Dechunking code in Apache 2.0.49

[Mathias Herberts <Ma...@iroise.net>]

Hi,

I've been deploying Apache 1.3 instances for many years now, relying 
heavily on the mod_proxy / mod_rewrite couple to build our HTTP backbone.

In the past year I've met a problem with the proxying of requests made 
by MIDP (mobile devices) clients. Those requests were using 
'Transfer-Encoding: chunked' and mod_proxy in Apache 1.3 was not willing 
to forward those requests correctly. I filed bug #17877 and provided a 
patch providing a workaround for this situation. My patch used 
REQUEST_CHUNKED_PASS instead of REQUEST_CHUNKED_ERROR in mod_proxy.c and 
passed unchanged the 'Transfer-Encoding: chunked' request header if it 
existed.

Even though there is a question in making mod_proxy pass hop by hop 
headers to the origin server as being legitimate, this patch solved my 
problem and has served us well since then.

I am now planning on rolling out Apache 2.0.49 and I am again faced with 
a similar problem. This time the 2.0.49 server is using mod_proxy / 
mod_rewrite / mod_dav and proxying DAV requests. DAV requests, 
especially those using method PUT rely heavily on 'Transfer-Encoding: 
chunked' as the data being PUT onto the DAV store might not have a known 
size in advance. The problem mentionend in bug #17877 happens again, but 
this time I do not see any easy way of patching httpd 2.0.49 as 
REQUEST_CHUNKED_PASS and the associated code has been removed back in 2000!

Is this issue a known one (I've not found anything in the bug DB about 
it apart from the bug I filed last year) or am I alone experiencing it? 
Is there any roadmap to make mod_proxy support the forwarding of chunked 
requests? Dechunking is really impractical in terms of memory 
consumption, just consider a PUT request writing an image file for a 
DVD, we're talking more than 4 gigs of data.

What is the position of the Apache community on the passing of 'hop by 
hop' headers to origin servers by mod_proxy? The code in proxy_http.c 
says 'RFC2616 13.5.1 says we should strip these headers', but RFC 2616 
13.5.1 defines 'Hop-by-hop headers, which are meaningful only for a 
single transport-level connection, and are not stored by caches or
  forwarded by proxies.' it never uses SHOULD or MUST as described in 
RFC 2119 and therefore allowing mod_proxy to forward the 
'Transfer-Encoding' header would not, IMHO, violate RFC 2616 13.5.1.

Any comment welcome,

regards,

Mathias.

Re: Dechunking code in Apache 2.0.49

[Graham Leggett <mi...@sharp.fm>]

Sumeet Singh wrote:

> I would think that mod_proxy should make an independant decision (based 
> on compliance with the RFC, mod_proxy's configuration, type of origin 
> server etc) on whether it should send a chunked or dechunked request 
> body. For example, if the client sent chunked data that was larger than 
> a configured threshold, and if the origin server connection was HTTP/1.1 
> then mod_proxy could re-chunk the request-body.
> 
> I agree, that since the data passing through the filters is in the form 
> of buckets - it has to be "unchunked" (and then filled into buckets).

The next question is: Is proxy responsible for this, or is one of the 
filters handling the incoming post responsible for this.

I strongly suspect this is not a proxy issue, but a filter issue.

Regards,
Graham
--

Re: Dechunking code in Apache 2.0.49

[Sumeet Singh <su...@openwave.com>]

I would think that mod_proxy should make an independant decision (based 
on compliance with the RFC, mod_proxy's configuration, type of origin 
server etc) on whether it should send a chunked or dechunked request 
body. For example, if the client sent chunked data that was larger than 
a configured threshold, and if the origin server connection was HTTP/1.1 
then mod_proxy could re-chunk the request-body.

I agree, that since the data passing through the filters is in the form 
of buckets - it has to be "unchunked" (and then filled into buckets).

Graham Leggett wrote:

> Jim Jagielski wrote:
>
>> I think there's been soem discussion, onlist as well as via Bugzilla, on
>> the best way to handle this. Personally, I think that if the client
>> sent chunked, we should pass that through to the origin server.
>
>
> As I remember, the client should try to remember whether the server 
> doesn't support HTTP/1.1, and not send chunked request bodies if so.
>
> Trouble is, the client sees Apache, which is an HTTP/1.1 server. So it 
> always sends chunked request bodies, because Apache is all the client 
> sees. So simply passing on the client's chunked response to the origin 
> server (whether temporarily un-chunked en-route through the filter 
> stack or not) doesn't seem to me to be doing the right thing.
>
> Unfortunately my copy of RFC2616 died along with my laptop harddrive, 
> so I can't check right now, but I will check the exact wording over 
> the weekend to be sure.
>
> Regards,
> Graham
> -- 
>

Re: Dechunking code in Apache 2.0.49

[Graham Leggett <mi...@sharp.fm>]

Jim Jagielski wrote:

> I think there's been soem discussion, onlist as well as via Bugzilla, on
> the best way to handle this. Personally, I think that if the client
> sent chunked, we should pass that through to the origin server.

As I remember, the client should try to remember whether the server 
doesn't support HTTP/1.1, and not send chunked request bodies if so.

Trouble is, the client sees Apache, which is an HTTP/1.1 server. So it 
always sends chunked request bodies, because Apache is all the client 
sees. So simply passing on the client's chunked response to the origin 
server (whether temporarily un-chunked en-route through the filter stack 
or not) doesn't seem to me to be doing the right thing.

Unfortunately my copy of RFC2616 died along with my laptop harddrive, so 
I can't check right now, but I will check the exact wording over the 
weekend to be sure.

Regards,
Graham
--

Re: Dechunking code in Apache 2.0.49

[Mathias Herberts <Ma...@iroise.net>]

Jim Jagielski wrote:

> 
> On Jun 3, 2004, at 5:02 PM, Mathias Herberts wrote:
> 
>> Hi,
>>
>> I've been deploying Apache 1.3 instances for many years now, relying 
>> heavily on the mod_proxy / mod_rewrite couple to build our HTTP backbone.
>>
>> In the past year I've met a problem with the proxying of requests made 
>> by MIDP (mobile devices) clients. Those requests were using 
>> 'Transfer-Encoding: chunked' and mod_proxy in Apache 1.3 was not 
>> willing to forward those requests correctly. I filed bug #17877 and 
>> provided a patch providing a workaround for this situation. My patch 
>> used REQUEST_CHUNKED_PASS instead of REQUEST_CHUNKED_ERROR in 
>> mod_proxy.c and passed unchanged the 'Transfer-Encoding: chunked' 
>> request header if it existed.
>>
> 
> I think there's been soem discussion, onlist as well as via Bugzilla, on
> the best way to handle this. Personally, I think that if the client
> sent chunked, we should pass that through to the origin server.

That was my initial thought too, but what Joe Orton and graham Leggett 
mentioned makes great sense, i.e. the filters expect dechunked data and 
  passing it through would break stuff. The idea of reissueing a chunked 
request if such a request was initially received seems to be the best 
thing to do.

Mathias.

Re: Dechunking code in Apache 2.0.49

[Jim Jagielski <ji...@jaguNET.com>]

On Jun 3, 2004, at 5:02 PM, Mathias Herberts wrote:

> Hi,
>
> I've been deploying Apache 1.3 instances for many years now, relying 
> heavily on the mod_proxy / mod_rewrite couple to build our HTTP 
> backbone.
>
> In the past year I've met a problem with the proxying of requests made 
> by MIDP (mobile devices) clients. Those requests were using 
> 'Transfer-Encoding: chunked' and mod_proxy in Apache 1.3 was not 
> willing to forward those requests correctly. I filed bug #17877 and 
> provided a patch providing a workaround for this situation. My patch 
> used REQUEST_CHUNKED_PASS instead of REQUEST_CHUNKED_ERROR in 
> mod_proxy.c and passed unchanged the 'Transfer-Encoding: chunked' 
> request header if it existed.
>

I think there's been soem discussion, onlist as well as via Bugzilla, on
the best way to handle this. Personally, I think that if the client
sent chunked, we should pass that through to the origin server.

Re: Dechunking code in Apache 2.0.49

[Joe Orton <jo...@redhat.com>]

On Fri, Jun 04, 2004 at 01:48:31AM +0200, Graham Leggett wrote:
> Mathias Herberts wrote:
> 
> >What is the position of the Apache community on the passing of 'hop by 
> >hop' headers to origin servers by mod_proxy? The code in proxy_http.c 
> >says 'RFC2616 13.5.1 says we should strip these headers', but RFC 2616 
> >13.5.1 defines 'Hop-by-hop headers, which are meaningful only for a 
> >single transport-level connection, and are not stored by caches or
> > forwarded by proxies.' it never uses SHOULD or MUST as described in RFC 
> >2119 and therefore allowing mod_proxy to forward the 'Transfer-Encoding' 
> >header would not, IMHO, violate RFC 2616 13.5.1.
> 
> The purpose of hop by hop headers are exactly that - they govern the 
> connection between each hop. Passing chunked encoding from the origin 
> server unchanged through the filter stack will break all the filters in 
> the chain, which are expecting raw data.
> 
> The correct fix for this is to make sure that any traffic that apache 
> passes through in either direction is _rechunked_ if a) the connection 
> is HTTP/1.1 and b) there is no content length on the request.

By "there is no content length" you really mean "there is a chunked
request body"?  HEAD has code to send a chunked request body, but only 
if explicitly configured to do so.

I think the correct approach is for the proxy to send a chunked request
body iff the client sent a chunked request body.  2616 presumably
requires that the proxy not do this if it knows that the next-hop server
is not HTTP/1.1 compliant (it could return a 411 instead rather than
buffer the body), but I don't think mod_proxy remembers that at the
moment.

joe

Re: Dechunking code in Apache 2.0.49

[Graham Leggett <mi...@sharp.fm>]

Mathias Herberts wrote:

> What is the position of the Apache community on the passing of 'hop by 
> hop' headers to origin servers by mod_proxy? The code in proxy_http.c 
> says 'RFC2616 13.5.1 says we should strip these headers', but RFC 2616 
> 13.5.1 defines 'Hop-by-hop headers, which are meaningful only for a 
> single transport-level connection, and are not stored by caches or
>  forwarded by proxies.' it never uses SHOULD or MUST as described in RFC 
> 2119 and therefore allowing mod_proxy to forward the 'Transfer-Encoding' 
> header would not, IMHO, violate RFC 2616 13.5.1.

The purpose of hop by hop headers are exactly that - they govern the 
connection between each hop. Passing chunked encoding from the origin 
server unchanged through the filter stack will break all the filters in 
the chain, which are expecting raw data.

The correct fix for this is to make sure that any traffic that apache 
passes through in either direction is _rechunked_ if a) the connection 
is HTTP/1.1 and b) there is no content length on the request.

It seems we're stripping the chunking on the way in (correctly) but then 
forgetting to put it back on the way out.

Regards,
Graham
--