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

Hi Boris,

On Aug 27, 2007, at 1:01 PM, Boris Zbarsky wrote:

>
> Robert Burns wrote:
>>>> 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].
> ...
>> <http://issues.apache.org/bugzilla/show_bug.cgi?id=14095#c9>
>
> That comment says that IIS defaults to a type.  It doesn't say that  
> there is no way to turn off the defaulting.  I don't know whether  
> there is; if someone with easy access to IIS could check, that  
> would be great.
>
> The Apache issue is not just that there is a default, but that it's  
> a bad default and there is no way to not have a default at all.   
> Luckily, it sounds like this will all change.  Another ten years,  
> and maybe UAs can start changing behavior accordingly...
>

I found this on MS IIS. Its not clear from me what the current state  
of IIS is from this, but it sound like they may have dropped the  
buggy behavior. It would be good to have someone with access to IIS  
confirm this.

http://support.microsoft.com/?id=326965

On the Wiki page, I created a new table to list results of the most  
recent browsers. If Gecko handles files differently for different  
header responses then just add those in a new row. For example, if  
the handling of LINK@href is different when the server responses with  
'text/plain' as opposed to ''application/octet-stream' (like you  
treat one as authoritative and the other requiring sniffing), then  
make separate rows for each header response.

<http://esw.w3.org/topic/HTML/ContentTypeIssues>

Fragment ID #head-011d17c37fc91b454f24a9b82bcbea468a6337d0

<http://esw.w3.org/topic/HTML/ 
ContentTypeIssues#head-011d17c37fc91b454f24a9b82bcbea468a6337d0>

Take care,
Rob

Received on Monday, 27 August 2007 19:11:05 UTC