* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #155 (closed design: fixed)

Opened 6 years ago

Last modified 4 years ago

Content Sniffing

Reported by: mnot@pobox.com Owned by:
Priority: urgent Milestone: 10
Component: p3-payload Severity: Active WG Document
Keywords: Cc:
Origin:

Description

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.

Attachments

155.diff (18.2 KB) - added by julian.reschke@gmx.de 6 years ago.
proposed change for part 3
155.2.diff (18.3 KB) - added by julian.reschke@gmx.de 6 years ago.
proposed change for part 3
i155.diff (2.0 KB) - added by julian.reschke@gmx.de 5 years ago.
Proposed extended text for P3 Section 3.2.1
i155.2.diff (2.0 KB) - added by julian.reschke@gmx.de 5 years ago.
Proposed extended text for P3 Section 3.2.1

Change History

Changed 6 years ago by julian.reschke@gmx.de

proposed change for part 3

Changed 6 years ago by julian.reschke@gmx.de

proposed change for part 3

comment:1 Changed 6 years ago by julian.reschke@gmx.de

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)

comment:2 Changed 6 years ago by mnot@pobox.com

  • Status changed from new to closed
  • Resolution set to fixed

comment:3 Changed 5 years ago by julian.reschke@gmx.de

  • Priority set to urgent
  • Milestone changed from unassigned to 08

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

comment:4 Changed 5 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution fixed deleted

comment:5 Changed 5 years ago by julian.reschke@gmx.de

From [663]:

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

comment:6 Changed 5 years ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to fixed

Changed 5 years ago by julian.reschke@gmx.de

Proposed extended text for P3 Section 3.2.1

comment:7 Changed 5 years ago by julian.reschke@gmx.de

  • Status changed from closed to reopened
  • Resolution fixed deleted

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

Changed 5 years ago by julian.reschke@gmx.de

Proposed extended text for P3 Section 3.2.1

comment:8 Changed 4 years ago by mnot@pobox.com

  • Milestone changed from 08 to 10

comment:9 Changed 4 years ago by julian.reschke@gmx.de

From [831]:

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

comment:10 Changed 4 years ago by julian.reschke@gmx.de

  • Status changed from reopened to closed
  • Resolution set to incorporated

comment:11 Changed 4 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:12 Changed 4 years ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.