Re: squid-2.4 and macs?

On Saturday 09 March 2002 11:21, Henrik Nordstrom wrote:
> This we have always been doing. It is not our fault if it is a
> http:// request. The origin server then forgot to set a "Vary:
> Accept-encoding" header telling caches that the content varies for
> different browsers.. (or the administrator is anonymizing away
> Vary:..)

Should also note the following small excerpt from RFC2616 which may
be read to put the blaim at the client if one likes to split hairs...:

      Note: If the request does not include an Accept-Encoding field,
      and if the "identity" content-coding is unavailable, then
      content-codings commonly understood by HTTP/1.0 clients (i.e.,
      "gzip" and "compress") are preferred; some older clients
      improperly display messages sent with other content-codings.
The
      server might also make this decision based on information about
      the particular user-agent or client.

Also note that HTTP/1.1 lacks a mechanism whereby the client can tell
the server which transfer-encodings it accepts, and that the
server->client mechanism is quite inefficient (rejecting requests
with unknown encodings as "501 Unimplemented"). Also note that
transfer-encoding is hop-by-hop, as opposed to content-encoding which
is end-to-end.

A good summary of Content-Encoding is:

7.2.1 Type

   When an entity-body is included with a message, the data type of
that
   body is determined via the header fields Content-Type and Content-
   Encoding. These define a two-layer, ordered encoding model:

       entity-body := Content-Encoding( Content-Type( data ) )

   Content-Type specifies the media type of the underlying data.
   Content-Encoding may be used to indicate any additional content
   codings applied to the data, usually for the purpose of data
   compression, that are a property of the requested resource. There
is
   no default encoding.

And the next paragraph clearly expresses one of the brokenness of
Microsoft IE:

   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".

Regards
Henrik
Received on Sat Mar 09 2002 - 03:38:26 MST