httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Elving <chris.elv...@Sun.COM>
Subject Re: mod_deflate and transfer / content encoding problem
Date Wed, 12 Nov 2003 23:22:51 GMT
TOKILEY@aol.com wrote:

>There also is no way, in current HTTP specs, for a Server
>to distinguish between "Content-encoding" and "Transfer-encoding"
>as far as what the client really means it can/can't do.
>
>When a User-Agent says "Accept-encoding: xxxx" a Server can
>only assume that it means it can handle the 'xxxx' encoding for
>EITHER "Content-encoding:" OR "Transfer-encoding:". There's
>just no way to tell the difference. Same HTTP request field
>is supposed to be good for BOTH 'Transfer' and 'Content'
>encoding.
>

My reading of RFC 2616 is that Accept-encoding is only for 
content-codings. Clients should indicate their ability to handle 
transfer-codings via TE.

>Content-Encoding: gzip
>together with
>Transfer-Encoding: chunked
>
>or simply...
>
>Transfer-Encoding: gzip, chunked.
>
>It should make no difference to the 'receiver'.
>

Well, not if the receiver is a caching proxy...

As far as I understand it, mod_deflate's practice of returning 
Content-encoding: gzip but using Transfer-encoding: gzip semantics (e.g. 
conditionally compressing a resource and using the same ETag for both 
the compressed and non-compressed forms of that resource) is potentially 
poisonous to proxies that handle Range.



Mime
View raw message