W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: Content Sniffing impact on HTTPbis - #155

From: Adrien de Croy <adrien@qbik.com>
Date: Sun, 14 Jun 2009 13:18:03 +1200
Message-ID: <4A344FCB.5010402@qbik.com>
To: Adam Barth <w3c@adambarth.com>
CC: Jamie Lokier <jamie@shareable.org>, ietf-http-wg@w3.org

OK..This does raise the question of what does a server do.

I don't know of any servers (in my relatively limited knowledge of 
servers) that doesn't just use the file extension to choose content type 
when serving. 

If the served type is supposed to be the authoritative reference, you 
get problems when a server has a smaller database of extension-to-type 
than the client.

Otherwise you'd need to re-engineer servers so that content providers 
can manually specify content type when providing content.  That then 
means authors need to know about registered types etc.

So I can't see this changing any time soon, no matter what we write into 
specs.

Adrien


Adam Barth wrote:
> On Sat, Jun 13, 2009 at 6:01 PM, Adrien de Croy<adrien@qbik.com> wrote:
>   
>> that code shows Chrome using the file extension to look up a content type
>> from the windows registry, so it's clearly showing Chrome using the file
>> extension to determine content type.  The fact that the DB of extension to
>> type is provided by the OS, doesn't alter the fact that Chrome is using it.
>>     
>
> You'd have to examine the callers of that function to see what it's
> used for.  It might not actually be called at all.  I think it's used
> in some security checks for downloaded files.  It's certainly not used
> by the sniffing algorithm.
>
> Adam
>
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Sunday, 14 June 2009 01:15:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:03 GMT