Re: [squid-users] "Accept-Encoding" header

From: "Henrik Nordstrom" <hno@squid-cache.org>

> You could help with the effort to make Squid HTTP/1.1 compliant... it
> is not a small task however due to the high complexity of HTTP/1.1
> and HTTP/1.0 interactions.

Yes, I know. I would be really glad to help you with content
compression/decompression and chunking/unchunking. Unfortunately, I'm very
busy right now with two heavy weight projects. Additionally, I'm already
volunteering to write the tutorial "Features of Content Compression for
Different Web Clients" for the mod_perl's web site. Hopefully, I will be
able to join the Squid project in the second half of October. We can discuss
details then. Anyway, I will be listening this list to keep in touch.

> Our you can use Content-Encoding within HTTP/1.0. It is only
> Transfer-encoding that is incompatible with HTTP/1.0 as it changes
> the hop-to-hop message format. (Content-Encoding is end-to-end, and
> does not change the message format, only the entity format within the
> message).

Unfortunately, it's not that simple. Content compression has not been
introduced at all in HTTP/1.0, and Content-Encoding was used by Netscape
mainly for their early experiments with content compression. Some of that
old browsers are still in use, but they are buggy usually. For example:

 Netscape 4.79 is still failing to
 a) handle <script> referencing compressed JavaScript files (Content-Type:
application/x-javascript);
 b) handle <link> referencing compressed CSS files (Content-Type:
text/css);
 c) display the source code of compressed HTML files;
 d) print compressed HTML files;

The client's vendor does not care to patch known bugs, since the nova days
of HTTP/1.1's implementation it is implied that HTTP/1.0 should not use any
content compression. This intuitive aproach is widely accepted by the
end-users since they obtained the option to choose the version of HTTP in
MSIE browser.

> What a HTTP/1.1 server MUST do when responding to a HTTP/1.0 request
> with HTTP/1.1 end-to-end features that may be incompatible with a
> HTTP/1.0 cache is to respond with a Expires header indicating that
> the object is expired immediately. In addition to this it should
> respond with the proper HTTP/1.1 headers such as Vary, Cache-control
> etc to allow HTTP/1.1 agents along the path (browsers and caches) to
> take benefit from the richer semantics of HTTP/1.1. This is the only
> way to safely use HTTP/1.1 extensions that affects reply entity
> format within HTTP/1.0.

I would not say for sure that this is safe... I'll think additionally and
let you know.

Thanks,
Slava
Received on Fri Jun 21 2002 - 15:17:13 MDT