Re: Content Sniffing impact on HTTPbis - #155

Adam Barth wrote:
> On Fri, Jun 12, 2009 at 4:05 PM, David Morris<dwm@xpasc.com> wrote:
>   
>> On Fri, 12 Jun 2009, Ian Hickson wrote:
>>     
>>> I don't mind making this requirement non-normative (since as you say it's
>>> implicit), but I do think we should explicitly state that file extensions
>>> don't and mustn't have an effect, since it is so common to use them for
>>> this exact purpose in clients.
>>>       
>> I find it absurd to disallow use of file extensions given that on most OSes,
>> there is no other mechanism to annotate content type. And they are a common
>> way web servers choose content/type values.
>>     
>
> For better or worse, we can't use file extensions as part of the
> content sniffing algorithm because it's insecure.  In many attack
> scenarios, the attacker chooses the file extension.
>
>   
I presume therefore you can't use the content-type or file content 
either, since these are also potentially provided by an attacker?

I'm not sure what a Windows client that wants to launch an external 
application will do if it can't use the file extension, unless there's 
some database in Windows that maps to executables on some index other 
than file extension?

How does Chrome handle this?

Regards

Adrien

>> Legislating our result into irrelevance is the likely outcome of dictating
>> against common practice without a better commonly available alternative.
>>     
>
> Neither Firefox nor Chrome uses the file extension in their sniffing
> algorithm.  Safari uses the file extension only in one corner case.  I
> don't think we legislating the algorithm to irrelevance with this
> requirement.
>
> Adam
>
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Saturday, 13 June 2009 02:55:15 UTC