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

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.

   http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/ 
mime.types

>>> 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.

    http://issues.apache.org/bugzilla/show_bug.cgi?id=13986

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  
would
have fixed it as an error.

....Roy

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