Re: Microsoft's "I mean it" content-type parameter

At 18:17  +0200 3/07/08, Julian Reschke wrote:
>Dave Singer wrote:
>>>>...
>>>>Also, it might it be invoked by servers which report *no* Content-Type?
>>>>...
>>>
>>>Well, that's totally ok. Servers that do not know the Content-Type 
>>>of a resource should not guess, which in turn allows the recipient 
>>>to sniff.
>>
>>but, as far as I can tell, there is no "unknown" content-type, is there?
>
>The way to signal "unknown" is not to send a Content-Type header at 
>all. As far as I understand, this is what happens with httpd trunk 
>when you set the DefaultType to "none".

or, it seems, "application/octet-stream".  From HTTP 1.1:

Any HTTP/1.1 message containing an entity-body SHOULD include a 
Content-Type header field defining the media type of that body. If 
and only if the media type is not given by a Content-Type field, the 
recipient MAY attempt to guess the media type via inspection of its 
content and/or the name extension(s) of the URI used to identify the 
resource. If the media type remains unknown, the recipient SHOULD 
treat it as type "application/octet-stream".

It does seem as if sniffing when there is a content-type header is 
flat-out forbidden.  I.e. the presence of content-type was supposed 
to serve *exactly* what the "I mean it" extension is doing...

Next up:  a server that always adds the "I mean it" attribute, even 
when it doesn't, and the subsequent invention of the "No, really, 
come on, you have to believe me, scout's honor, I really truly mean 
it" extension.
-- 
David Singer
Apple/QuickTime