Re: review of content type rules by IETF/HTTP community

On Fri, 24 Aug 2007 22:50:26 +0200, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:

> Robert Burns wrote:
>
>> a missing filename extension (needed once the file goes tot he server  
>> or is accessed using HTTP).
>
> For what it's worth, Apache does have a mode where it will use  
> content-sniffing instead of filename extensions to determine the types  
> it will send.  It's not enabled by default (which is too bad), and I  
> don't know how commonly it's used.
>
>> I suspect the server mapping issue is a big source of the problem.
>
> Absolutely.  It's particularly a problem when a "new" extension that the  
> server is not aware of appears or becomes popular.
>
>> Typically the problem may occur when new file formats become common  
>> where the server has been installed and configured long before those  
>> formats (and their associated filename extensions) came onto the scene.
>
> As a UA developer, I can say that this is in fact the situation that  
> forced Gecko to add text/plain sniffing.

It doesn't just apply to new format and old servers either. Apache does  
not include several common extensions in its mime mappings, as I  
understand it because there is a policy of only supporting IANA-registered  
types. Many of these are old and well-established, so there is little  
chance of them deciding to change their mind and register any time soon. I  
doubt Apache is alone, surely other web servers have their own ways to  
ensure not all content works as it should out of the box.

The consequences are externalized to server admins to fix things on their  
own (e.g. with [1]) and UA implementors to make it work even when it's not  
fixed. I have low hopes for this problem being solved by the servers.

[1]  
http://developer.mozilla.org/en/docs/Properly_Configuring_Server_MIME_Types

-- 
Magnus Kristiansen
"Don't worry; the Universe IS out to get you."

Received on Friday, 24 August 2007 23:31:53 UTC