Sniffing and HTTP-bis (ACTION-309)

Hash: SHA1

At the TAG f2f in September, we discussed [1] Content-Type sniffing
and the then-current state of the HTTPbis [2] insofar as it addresses
this question (see section 3.2.1 *Type*).

As it stands the draft only indirectly alludes to sniffing, in the
following paragraph:

  Content-Type specifies the media type of the underlying data. Any
  HTTP/1.1 message containing an entity-body SHOULD include a
  Content-Type header field defining the media type of that body,
  unless that information is unknown. If the Content-Type header field
  is not present, it indicates that the sender does not know the media
  type of the data; recipients MAY either assume that it is
  "application/octet-stream" ([RFC2046], Section 4.5.1) or examine the
  content to determine its type.

Mark Nottingham joined our discussion in September, and said at one

  "We were asked to confirm that HTTP bis doesn't conflict with
   sniffing, and we decided to accept that."

In later discussion, I said:

  "I heard TBL say things which suggest we should push back on the
   current state of the HTTP bis draft. Because it doesn't say 'Don't
   do that: sniffing breaks things'"

I took an action [3] to review the situation, and suggest further action
if necessary.

I think we should in fact request the HTTPbis editors to reopen their
Ticket #155 [4] with a suggestion that something along the following
lines be added after the above-quoted paragraph in section 3.2.1:

  If the Content-Type header field _is_ present, recipients SHOULD NOT
  examine the content and override the specified type if the change
  would significantly alter the security exposure ('privilege

This change is compatible with _Content-Type Processing Model_, a
draft "responsible sniffing" Internet-Draft [5].

- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail:
[mail really from me _always_ has this .sig -- mail without it is forged spam]
Version: GnuPG v1.2.6 (GNU/Linux)


Received on Wednesday, 2 December 2009 12:24:33 UTC