Re: Content Sniffing impact on HTTPbis - #155

On Jun 6, 2009, at 9:17 PM, Adam Barth wrote:
> On Sat, Jun 6, 2009 at 12:16 AM, Roy T. Fielding  
> <fielding@gbiv.com> wrote:
>> On Jun 6, 2009, at 8:43 AM, Adam Barth wrote:
>>> I seem to recall that here are a bunch of servers that send
>>> Content-Type: application/gzip when they mean Content-Encoding: gzip
>>> (or is it vice-versa?).  I can look up the code if you'd like more
>>> information.
>>
>> No, they send app/gzip as the content-type when they do not want
>> the recipient to remove the encoding on-the-fly.  That is a
>> typical config for software distribution sites.
>
> So, I looked it up.  Apparently Apache (maybe an old version?) sends
> *both* Content-Encoding: gzip and Content-Type: application/gzip for
> files that end in ".gz".  To work around this bug, some popular user
> agents ignore the Content-Encoding in this case.

I don't know of any version of Apache that would do that, but if you
see a specific version in the wild let me know (third-party distros  
often
introduce bugs that we don't know about).  There are literally dozens of
ways to set that metadata in Apache, only a few of which involve file
extensions, so it is certainly possible to configure Apache to send  
both.

> I'm not suggesting we spec this behavior.  The point is more that
> reality sometimes forces user agents to doctor the Content-Encoding.

It is also possible to gzip a gzipped document, so reality should be
asking the browser to treat it as such.  In any case, the normal
behavior is to leave the encoding as is unless the media type is
one of those rendered by the browser, so it is unlikely we'd see
a difference in behavior even if the config is weird.

....Roy

Received on Saturday, 6 June 2009 20:23:15 UTC