- From: Dave Singer <singer@apple.com>
- Date: Thu, 3 Jul 2008 12:28:56 -0400
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Jamie Lokier <jamie@shareable.org>, "William A. Rowe, Jr." <wrowe@rowe-clan.net>, Robert Collins <robertc@robertcollins.net>, HTTP Working Group <ietf-http-wg@w3.org>, "public-html@w3.org" <public-html@w3.org>
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
Received on Thursday, 3 July 2008 16:31:07 UTC