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

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

From: Robert Burns <rob@robburns.com>
Date: Mon, 27 Aug 2007 00:28:32 -0500
Message-Id: <31F68351-BDAF-4517-BE7C-3A77B55F698D@robburns.com>
Cc: public-html@w3.org
To: Roy T.Fielding <fielding@gbiv.com>

Hi Roy,

On Aug 26, 2007, at 10:02 PM, Roy T. Fielding wrote:

> On Aug 26, 2007, at 1:39 PM, Robert Burns wrote:
>> On Aug 26, 2007, at 3:32 PM, Julian Reschke wrote:
>>> Robert Burns wrote:
>>>>> 1) Where's the advantage over "application/octet-stream"?
>>>> The advantage is that UAs are not supposed to sniff for content  
>>>> when the content is delivered with a MIME type from the server  
>>>> that's supposed to be treated as authoritative. Sending  
>>>> 'unknown', could be defined by RFC and IANA as meaning  
>>>> specifically the same as not sending a content-type header at all.
>>> Understood. But that requires changes in the UAs. How exactly is  
>>> this better compared to installing fixes for Apache?
>> Well the request to fix Apatche goes back over 5 years and Apache  
>> does not seem interested in fixing it. I was proposing another way  
>> to go that didn't rely on Apache.
> Apache is a foundation consisting of over 1500 volunteers across 50 or
> so major projects, and about 75 products.  Apache doesn't do anything.
> Individuals do things at Apache, all volunteers, and we work on  
> whatever
> can grab our attention at the time.

First, let me say its great news that this bug will get the attention  
it deserves after so long. Reading through those comments   
especially the nay sayers  was like reading through comments from a  
strange alternate universe. Second, I understand that Apache is a  
large organization with differences of opinions. That's what may be  
think that one voice  even yours  might not be enough to sway the  
group. After all some of the commenters raised what they claimed were  
grave concerns about breaking compatibility if the bug were fixed.

> The DefaultType stuff came from 13 years ago when there were only a
> dozen or so file types on the Web and *everything* else was indeed
> plain text with no file extensions at all (the typical Unix habit).
> The only real problem with it as a feature is that there does not
> appear to be a way to turn it off, which is indeed a bug.  If I had
> known about that bug, it would have been fixed, but it's been over a
> decade since I personally had time to go through all of the old
> enhancement requests to look for issues like this one.

Yes, it sounds like the real intent of DefaultType was really  
NoExtension or something along those lines, though today, even that  
might be better handled through the MIMEMagic extension.

>>>>> 2) You may want to look at <http://issues.apache.org/bugzilla/ 
>>>>> show_bug.cgi?id=13986#c55>.
>>>> Yes, I did. In fact I cited it in my message. My comments were  
>>>> drawn substantially from reading the comments in that bug. It  
>>>> sounds like Apache does not want to fix the bug even though  
>>>> Boris long-ago submitted a patch. Using a IANA registered  
>>>> 'unknown' MIME type would accomplish the same thing (as long as  
>>>> the servers could be configured and pre-configured with  
>>>> 'DefaultType unknnown'.
>>> No, I meant comment #55 in that bug: It's going to be fixed soon.  
>>> See also <http://mail-archives.apache.org/mod_mbox/httpd-dev/ 
>>> 200708.mbox/%3cDD9034EC-D3F4-4AF7-8AC1-8666A3B94C32@gbiv.com%3e>.
>> Well comment # 55 is only the last in a long list of comments  
>> ignored by Apache. Boris has alrready provide a patch and that was  
>> ignored. I'm not really clear what you're asking about here. Roy  
>> may provide a patch and that could be ignored.
> I have a bit more influence over the process.  More importantly, I can
> commit the change myself if all of the other maintainers agree, which
> is why Julian seems so puzzled by your comments.

That's great news. The other concern that may still make it  
worthwhile to pursue a 'unknown' IANA registered MIME type is that  
IIS appears to have the same bug (at least form the comments) on the  
related bug[1]. Unless that commenter is incorrect, it sounds like  
IIS also cannot be configured to not send a MIME type when it doesn't  
know the type.

>> And that patch does nothing for the enormous installed base of  
>> Apache 1.3 installations. Apple (which is my Apache vendor) is  
>> still selling products with Apache 1.3 as the default server.  
>> Maybe that will change this year. I don't know, but it would be  
>> good to get this on the older servers too.
> As I said, there are at least five other ways to define a media type
> and override anything in mime.types -- the notion that there is any
> lack of such ability is complete bollocks.  What is lacking is good
> documentation at each ISP for the particular set of ways that they
> allow an author to override those mappings.  Anyone who wants to
> contribute such documentation can do so -- the easiest way is to make
> use of our wiki at
>    http://wiki.apache.org/httpd/

I'm not sure I read anyone claiming there were not sufficient ways to  
set MIME type. There certainly are many ways to do so. However, one  
of the strengths of these servers and the HTTP protocol is that it is  
largely a set and forget product. One commenter suggested that if the  
server admin couldn't handle proper configuration, they should be  
fired (or something to that effect). Well in most cases they have  
already been fired because they just weren't needed. It is in the  
rare instances when new filename extensions pop onto the scene that  
anyone is needed to update the server. Many of those cases would not  
even be absolutely necessary if the major servers weren't designed to  
just make up an answer when they didn't know the answer. Consider the  
frequent example given of .dmg files that get sent by Apache as text/ 
html. This was a fairly recent filename extensions in the life of  
httpd. However browsers have to ignore the content-type sent by  
Apache or they would end up displaying the text/html rendition of  
the .dmg file as a page full of gibberish. Sure that's a  
configuration problem, but its a configuration problem compounded by  
this bug.

It is just surprising to me that a bug like this, where Apache's  
httpd was actually designed to violate the http protocol would not  
get escalated and brought to someone's attention for many years, if  

Take care,

[1]: <http://issues.apache.org/bugzilla/show_bug.cgi?id=14095>
Received on Monday, 27 August 2007 05:28:48 UTC

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