On 15 Oct 2003, Gonzalo Arana wrote:
> > Content-Encoding should not be done in a proxy unless you know exacly what
> > you are doing. There is very fargoing implications of applying
> > Content-Encoding to a entity.
>
> OUCH! ok, were may I read about it? (appart RFCs containing
> 'Content-Encoding').
RFC2616 actually contains all the required information, but is a little
lengthy to read and not always obvious.
The short version:
Content-Encoding is a entity property just as Content-Type etc, and
modifying Content-Encoding creates a new entity. Entities are owned by the
origin server and proxies are not really supposed to create new entities.
Content-Encoding is primarily designed for use when the web server stores
multiple different encodings of the same data, not really for on-the-fly
transformations.
Ignoring the fact that proxies are not supposed to create new entities,
when you create a new entity you MUST make sure to give the new entity a
new identity. Entity identities are assigned via the ETag header. If you
do not then all the conditional HTTP processing may fail badly, for
example as used when merging different ranges of the same entity.
> > Transfer-Encoding may be done freely in a proxy with no implications,
> > except that HTTP/1.1 support is needed...
>
> mmm I want to compress text/(html|plain) responses to my dial-up users.
> This can't be done with Transfer-Encoding, am I wright?
This can be done fine with Transfer-Encoding using the gzip
Transfer-Encoding. Transfer-Encoding is designed for use in proxies and
other on-the-fly transformations and does not modify the entity, it just
compresses the response in case of gzip encoding.
The main semantic difference between Transfer-Encoding and
Content-Encoding is that Transfer-Encoding is a property of the
transmission of the response, not a property of the entity.
Transfer-Encoding applies hop-by-hop while Content-Encoding applies
end-to-end.
Note: The lack of Transfer-Encoding support is the primary reason why
Squid is not yet HTTP/1.1.
Regards
Henrik
Received on Thu Oct 16 2003 - 02:10:40 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:20:44 MST