- From: Mark Baker <mark@coactus.com>
- Date: Tue, 31 Mar 2009 14:13:47 +0000
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Mar 30, 2009 at 7:58 PM, Mark Nottingham <mnot@mnot.net> wrote: > [ As discussed in SF ] > > Browsers now routinely 'sniff' content to determine its type, sometimes in > conflict with the media type conveyed in the Content-Type header. The > reasons most often cited for this practice are the misconfiguration of > servers, the inability of content authors to configure servers (either for > technical reasons or lack of education), and generally the incentives placed > upon browser vendors to "just work." > > p3-payload section 3.2.1. currently says: >> >> 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". > > which effectively disallows this practice, despite widespread use that > (apparently) isn't stopping any time soon. That paragraph doesn't seem to me to apply to the typical sniffing scenario discussed by draft-abarth-mime-sniff, as it deals only with unspecified media types rather than their intentional overriding. Obviously that kind of sniffing is widespread amoungst one class of agent, and I'm all for documenting how it works, but IMO that has no place in the protocol specification, save perhaps for an informative note that it happens and a pointer to the algorithm. Mark.
Received on Tuesday, 31 March 2009 18:16:39 UTC