W3C home > Mailing lists > Public > public-html@w3.org > August 2007

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

From: Roy T. Fielding <fielding@gbiv.com>
Date: Sat, 25 Aug 2007 12:25:29 -0700
Message-Id: <DFD12646-E99B-4D5A-8081-880BB80044FE@gbiv.com>
Cc: "Julian Reschke" <julian.reschke@gmx.de>, public-html@w3.org
To: Magnus Kristiansen <magnusrk+w3c@pvv.org>

On Aug 25, 2007, at 4:55 AM, Magnus Kristiansen wrote:
> On Sat, 25 Aug 2007 10:17:14 +0200, Julian Reschke  
> <julian.reschke@gmx.de> wrote:
>> Magnus Kristiansen wrote:
>>> 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
>> Who are "they"? Anybody can try to register a type. The  
>> registration procedure is here: <http://tools.ietf.org/html/rfc4288>.
> .gz and .rar are notoriously absent, as are several Microsoft audio/ 
> video formats. A more recent addition is bittorrent.

.gz is set in the httpd.conf using AddType -- it has to be that way
because some people prefer it to be a Content-Encoding.  Does rar have
a type?  BTW, there are at least five other ways to set a media type
in Apache, and almost all ISPs provide a GUI (cpanel, etc.) to do so.

> Other types like .ico, .avi, .wav and flash's .swf are also  
> unregistered, but have somehow found their way into the mime.types  
> file regardless.

Patches to trunk are always useful.  If you get one to me by  
tomorrow, it
might even make it into the next release.


>>> 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
>> Well, at least for Apache httpd the default is *not* to send a  
>> content-type response header when the type is unknown. As far as I  
>> can tell, we're discussing something completely different here:  
>> servers that send an incorrect type.
> This does not match my tests. I removed my custom types, and as  
> expected .wmv was served as text/plain. Not just displayed as text,  
> an explicit content-type header.

You are right -- that was supposed to be fixed a couple years ago when
I removed the default charset.  I just upgraded the PR status.


Note: Apache httpd does not hold dev discussions in bugzilla, so a huge
amount of discussion on this topic was never seen by the people who  
have fixed it as an error.

Received on Saturday, 25 August 2007 19:25:41 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC