You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by gw...@fscinternet.com on 2002/07/26 17:46:45 UTC
mod_proxy drops the content-length header
In case anyone is interested, here are some captures taken with Sniffer
Pro. The key things to note are that Apache 2.0.39 mod_proxy drops the
Content-Length header, and also that it inserts "Content-Type:
text/plain". This behaviour is causing Web-Polygraph to report
superfluous errors.
Graham Wiseman
gwiseman@fscinternet.com
FSC Internet Corp.
** Original request from client:
HTTP: Line 1: GET /w06df39e0.4a3e422c:00000006/t04/_0000000e
HTTP/1.0
HTTP: Line 2: Accept: */*
HTTP: Line 3: Host: target1.lab.fscinternet.com:80
HTTP: Line 4: X-Xact: 06df39e0.4a3e422c:00000002
06df39e0.4a3e422c:000000b2
HTTP: Line 5: X-Loc-World: 06df39e0.4a3e422c:00000006 -1/14 7
HTTP: Line 6: X-Rem-World: 06df39e0.4a3e422c:00000006 -1/14 7
HTTP: Line 7: X-Target: 10.249.1.50:80
HTTP: Line 8: X-Abort: 1433599079 1880685060
HTTP: Line 9: X-Phase-Sync-Pos: 0
HTTP: Line 10: Connection: keep-alive
** Proxied request from Apache 2.0.39 mod_proxy:
HTTP: Line 1: GET /w06df39e0.4a3e422c:00000006/t04/_0000000e
HTTP/1.1
HTTP: Line 2: Host: target1.lab.fscinternet.com
HTTP: Line 3: Accept: */*
HTTP: Line 4: X-Xact: 06df39e0.4a3e422c:00000002
06df39e0.4a3e422c:000000b2
HTTP: Line 5: X-Loc-World: 06df39e0.4a3e422c:00000006 -1/14 7
HTTP: Line 6: X-Rem-World: 06df39e0.4a3e422c:00000006 -1/14 7
HTTP: Line 7: X-Target: 10.249.1.50:80
HTTP: Line 8: X-Abort: 1433599079 1880685060
HTTP: Line 9: X-Phase-Sync-Pos: 0
HTTP: Line 10: Max-Forwards: 10
HTTP: Line 11: X-Forwarded-For: 10.101.0.6
HTTP: Line 12: X-Forwarded-Host: target1.lab.fscinternet.com:80
HTTP: Line 13: X-Forwarded-Server: target1.lab.fscinternet.com
** Response from server:
HTTP: Line 1: HTTP/1.0 200 OK
HTTP: Line 2: Cache-Control: public
HTTP: Line 3: Date: Thu, 25 Jul 2002 23:05:23 GMT
HTTP: Line 4: Connection: keep-alive
HTTP: Line 5: Expires: Sun, 15 Dec 2002 19:26:25 GMT
HTTP: Line 6: Last-Modified: Tue, 18 Jun 2002 11:11:47 GMT
HTTP: Line 7: Content-Length: 34879
HTTP: Line 8: X-Target: 10.249.1.50:80
HTTP: Line 9: X-Xact: 06df39d3.7dbd4c7b:00000002
06df39e0.4a3e422c:7fffff4d
HTTP: Line 10: X-Abort: 1501744696 447802481
HTTP: Line 11: X-Phase-Sync-Pos: 0
** Proxied response from Apache 2.0.39 mod_proxy:
HTTP: Line 1: HTTP/1.1 200 OK
HTTP: Line 2: Date: Thu, 25 Jul 2002 23:05:23 GMT
HTTP: Line 3: Server: Apache
HTTP: Line 4: Cache-Control: public
HTTP: Line 5: Expires: Sun, 15 Dec 2002 19:26:25 GMT
HTTP: Line 6: Last-Modified: Tue, 18 Jun 2002 11:11:47 GMT
HTTP: Line 7: X-Target: 10.249.1.50:80
HTTP: Line 8: X-Xact: 06df39d3.7dbd4c7b:00000002
06df39e0.4a3e422c:7fffff4d
HTTP: Line 9: X-Abort: 1501744696 447802481
HTTP: Line 10: X-Phase-Sync-Pos: 0
HTTP: Line 11: Connection: close
HTTP: Line 12: Content-Type: text/plain
Re: mod_proxy drops the content-length header
Posted by Jeff Trawick <tr...@attglobal.net>.
Graham Leggett <mi...@sharp.fm> writes:
> Jeff Trawick wrote:
>
> > Agreed, as long as you really mean "zap the content-length header"
> > when you say "update the value of the content-length header".
> > A filter can't ever be *required* to put in the proper content-length
> > value. All it can usually do is zap the content-length header and
> > rely on the core to do the right thing (using the content-length
> > filter or chunked encoding).
>
> What I mean is that when filter-x is run, a content-length header
> might exist, ie it cannot be assumed at any point that a
> content-length header does not exist.
>
> If as you say the content-length is zapped and readded by another
> filter, that's fine then. A filter should not make assumptions about
> what headers may or may not exist before it is run.
>
> (am I making sense?)
I think we agree :)
. proxy should leave the content-length header alone
. the content-length filter needs to be added for this path
If a filter changes the content-length then its logic is irrespective
of whether or not this is a proxied request.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: mod_proxy drops the content-length header
Posted by Graham Leggett <mi...@sharp.fm>.
Jeff Trawick wrote:
> Agreed, as long as you really mean "zap the content-length header"
> when you say "update the value of the content-length header".
>
> A filter can't ever be *required* to put in the proper content-length
> value. All it can usually do is zap the content-length header and
> rely on the core to do the right thing (using the content-length
> filter or chunked encoding).
What I mean is that when filter-x is run, a content-length header might
exist, ie it cannot be assumed at any point that a content-length header
does not exist.
If as you say the content-length is zapped and readded by another
filter, that's fine then. A filter should not make assumptions about
what headers may or may not exist before it is run.
(am I making sense?)
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm
"There's a moon
over Bourbon Street
tonight..."
Re: mod_proxy drops the content-length header
Posted by Jeff Trawick <tr...@attglobal.net>.
Graham Leggett <mi...@sharp.fm> writes:
> Justin Erenkrantz wrote:
>
> > I believe it would be possible for the proxy to delete the
> > content-length header and replace it with another mechanism
> > of its choosing to signal the entity-length.
>
> From what I can see proxy removes the content-length, and then relies
> on one of the filters to either put the content length back, or use
> chunked encoding.
>
> Trouble is the initial request was an HTTP/1.0 request, not HTTP/1.1,
> which does not understand chunking. It looks like the filter in the
> HTTP/1.0 case doesn't readd the content-length header.
>
> To be honest, I don't think the content-length header should be
> removed in the first place in proxy. If a filter needs to modify the
> content length for any reason, it should update the value of the
> content-length header itself.
Agreed, as long as you really mean "zap the content-length header"
when you say "update the value of the content-length header".
A filter can't ever be *required* to put in the proper content-length
value. All it can usually do is zap the content-length header and
rely on the core to do the right thing (using the content-length
filter or chunked encoding).
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: mod_proxy drops the content-length header
Posted by Graham Leggett <mi...@sharp.fm>.
Bill Stoddard wrote:
>>To be honest, I don't think the content-length header should be removed
>>in the first place in proxy. If a filter needs to modify the content
>>length for any reason, it should update the value of the content-length
>>header itself.
>
>
> That sounds right to me.
Making proxy not touch content-length will fix the HTTP/1.0 case.
I want to commit a patch to fix this... any +1's...?
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm
"There's a moon
over Bourbon Street
tonight..."
RE: mod_proxy drops the content-length header
Posted by Bill Stoddard <bi...@wstoddard.com>.
> Justin Erenkrantz wrote:
>
> > I believe it would be possible for the proxy to delete the
> > content-length header and replace it with another mechanism
> > of its choosing to signal the entity-length.
>
> From what I can see proxy removes the content-length, and then relies
> on one of the filters to either put the content length back, or use
> chunked encoding.
>
> Trouble is the initial request was an HTTP/1.0 request, not HTTP/1.1,
> which does not understand chunking. It looks like the filter in the
> HTTP/1.0 case doesn't readd the content-length header.
>
> To be honest, I don't think the content-length header should be removed
> in the first place in proxy. If a filter needs to modify the content
> length for any reason, it should update the value of the content-length
> header itself.
That sounds right to me.
Bill
Re: mod_proxy drops the content-length header
Posted by Graham Leggett <mi...@sharp.fm>.
Justin Erenkrantz wrote:
> I believe it would be possible for the proxy to delete the
> content-length header and replace it with another mechanism
> of its choosing to signal the entity-length.
From what I can see proxy removes the content-length, and then relies
on one of the filters to either put the content length back, or use
chunked encoding.
Trouble is the initial request was an HTTP/1.0 request, not HTTP/1.1,
which does not understand chunking. It looks like the filter in the
HTTP/1.0 case doesn't readd the content-length header.
To be honest, I don't think the content-length header should be removed
in the first place in proxy. If a filter needs to modify the content
length for any reason, it should update the value of the content-length
header itself.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm
"There's a moon
over Bourbon Street
tonight..."
Re: mod_proxy drops the content-length header
Posted by Joshua Slive <jo...@slive.ca>.
On Sat, 27 Jul 2002, Justin Erenkrantz wrote:
> On Fri, Jul 26, 2002 at 11:46:45AM -0400, gwiseman@fscinternet.com wrote:
> > In case anyone is interested, here are some captures taken with Sniffer
> > Pro. The key things to note are that Apache 2.0.39 mod_proxy drops the
> > Content-Length header, and also that it inserts "Content-Type:
> > text/plain". This behaviour is causing Web-Polygraph to report
> > superfluous errors.
>
> Section 13.5.2 of 2616 seems to have some thoughts on this, but
> the wording seems a bit muddled.
See also:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8677
Joshua.
Re: mod_proxy drops the content-length header
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Jul 26, 2002 at 11:46:45AM -0400, gwiseman@fscinternet.com wrote:
> In case anyone is interested, here are some captures taken with Sniffer
> Pro. The key things to note are that Apache 2.0.39 mod_proxy drops the
> Content-Length header, and also that it inserts "Content-Type:
> text/plain". This behaviour is causing Web-Polygraph to report
> superfluous errors.
Section 13.5.2 of 2616 seems to have some thoughts on this, but
the wording seems a bit muddled.
A Content-Length is a end-to-end header (generally non-modifiable),
and 13.5.2 says:
The Content-Length field of a request or response is added or deleted
according to the rules in section 4.4. A transparent proxy MUST
preserve the entity-length (section 7.2.2) of the entity-body,
although it MAY change the transfer-length (section 4.4).
I believe it would be possible for the proxy to delete the
content-length header and replace it with another mechanism
of its choosing to signal the entity-length. But, the question is
whether we want to also send the C-L (if known) when doing a
connection close. That's an option.
As far as adding Content-Type, section 13.5.2 says:
A proxy MUST NOT modify or add any of the following fields in a
message that contains the no-transform cache-control directive, or in
any request:
...
- Content-Type
...
I'm not sure how to parse the 'or in any request' bit. Does that
apply to all requests or just those with no-transform cache-control
set? If it is free to modify it, then I think I can make a case
that the DefaultType directive applies. But, I'm not 100% sold on
that, either. -- justin
Re: mod_proxy drops the content-length header
Posted by Graham Leggett <mi...@sharp.fm>.
gwiseman@fscinternet.com wrote:
> In case anyone is interested, here are some captures taken with Sniffer
> Pro. The key things to note are that Apache 2.0.39 mod_proxy drops the
> Content-Length header, and also that it inserts "Content-Type:
> text/plain". This behaviour is causing Web-Polygraph to report
> superfluous errors.
The adding of text/plain has been reported before. According to RFC2616:
Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If
and only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its
content and/or the name extension(s) of the URI used to identify the
resource. If the media type remains unknown, the recipient SHOULD
treat it as type "application/octet-stream".
So, reading from the above your original application "should" have a
content-type already (it doesn't), and Apache "should" interpret it as
"application/octet-stream" (it doesn't either, it interprets it as
"text/plain"). Unfortunately RFC2616 doesn't seem to specify what is
supposed to happen if the "should" condition is not met.
Either way, the bug is not in mod_proxy but in the output filters that
handle the response. mod_proxy doesn't touch content-type.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm
"There's a moon
over Bourbon Street
tonight..."