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

On Sat, 25 Aug 2007 21:25:29 +0200, Roy T. Fielding <fielding@gbiv.com>
wrote:

@Roy: If you get this message twice, sorry.

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

rar is application/x-rar-compressed. And the issue is not whether it's
possible to fix your server, but rather that the server needs fixing in
the first place. Who is "wrong" is another discussion, because either way
browsers end up having to handle incorrectly marked content.

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

Patches to remove useful types? Forgive me if I'm not keen on providing
those. :)

If you mean patches to add types, much of it has already been reported (in
vain). [1] [2] [3]

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

It's good to hear improvements are being made.

[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=8633
[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=20440
[3] http://issues.apache.org/bugzilla/show_bug.cgi?id=22580

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

Received on Saturday, 25 August 2007 20:10:08 UTC