Content Sniffing

[mnot@…]

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.

The language should be updated to reflect this reality, without unduly encouraging the use of sniffing except where necessary. Ideally, it will be done in such a way that:

• Does not require sniffing for all uses of HTTP (i.e., a particular implementation and/or user can "opt in" to the use of a sniffing algorithm), since this is most commonly a problem for the browser case, and
• Specifically allows a user and/or content provider to opt out of the use of sniffing in a particular interaction, and
• Promotes interoperability (i.e., if two implementations sniff, they will do so in the same way).

See:

​http://tools.ietf.org/html/draft-abarth-mime-sniff

for a proposal sourced from HTML5.

Besides the issue of sniffing itself, there's also an open question of whether the sniffing algorithm would remain in a separate document (i.e., our work would only be to relax requirements to allow it), or whether it would be in-document.

In either case, we'd have to take a serious look at security considerations, and also look at impact on intermediaries, etc.

Note that this is not about sniffing encoding directly (see issue #20), although the resolution may be related.

[julian.reschke@…]

proposed change for part 3

[julian.reschke@…]

proposed change for part 3

[julian.reschke@…]

From [592]:

Rephrase "Content-Type" discussion so that it is clear that leaving it out can be better than server-side guessing, and that HTTP itself does not rule out client-side sniffing (related to #155)

[julian.reschke@…]

Proposal from HTTP WG meeting: remove the sentence:

"Note that neither the interpretation of the data type of a message nor the behaviors caused by it are defined by HTTP; this potentially includes examination of the content to override any indicated type ("sniffing")."

-- ​http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-07.html#rfc.section.3.2.1.p.5

[julian.reschke@…]

From [663]:

take out note about content-sniffing as discussed in HTTPbis Working Group meeting (related to #155)

[julian.reschke@…]

Proposed extended text for P3 Section 3.2.1

[julian.reschke@…]

TAG has requested more text, see discussion following ​http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0320.html

[julian.reschke@…]

Proposed extended text for P3 Section 3.2.1

[julian.reschke@…]

From [831]:

Say a bit more about the fact that some clients do sniff, and why this can be very dangerous (see #155)