Opened 14 years ago
Closed 12 years ago
#155 closed design (fixed)
Content Sniffing
Reported by: | mnot@… | Owned by: | |
---|---|---|---|
Priority: | urgent | Milestone: | 10 |
Component: | p3-payload | Severity: | Active WG Document |
Keywords: | Cc: |
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:
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 (4)
Change History (16)
Changed 14 years ago by julian.reschke@…
comment:1 Changed 14 years ago by julian.reschke@…
comment:2 Changed 14 years ago by mnot@…
- Resolution set to fixed
- Status changed from new to closed
comment:3 Changed 14 years ago by julian.reschke@…
- Milestone changed from unassigned to 08
- Priority set to urgent
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 14 years ago by mnot@…
- Resolution fixed deleted
- Status changed from closed to reopened
comment:5 Changed 14 years ago by julian.reschke@…
comment:6 Changed 13 years ago by mnot@…
- Resolution set to fixed
- Status changed from reopened to closed
comment:7 Changed 13 years ago by julian.reschke@…
- Resolution fixed deleted
- Status changed from closed to reopened
TAG has requested more text, see discussion following http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0320.html
comment:8 Changed 13 years ago by mnot@…
- Milestone changed from 08 to 10
comment:9 Changed 13 years ago by julian.reschke@…
comment:10 Changed 13 years ago by julian.reschke@…
- Resolution set to incorporated
- Status changed from reopened to closed
comment:11 Changed 12 years ago by mnot@…
- Resolution incorporated deleted
- Status changed from closed to reopened
comment:12 Changed 12 years ago by mnot@…
- Resolution set to fixed
- Status changed from reopened to closed
proposed change for part 3