Re: Content Sniffing impact on HTTPbis - #155

Mark Nottingham wrote:
> Sounds like we're moving towards consensus (because no one is 
> particularly happy).
> ...

I have attached a proposed patch to ticket 155, containing Mark's 
proposal (plus the removal of the surplus "not", plus an explicit 
reference to the spec defining application/octet-stream): see 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/155/155.diff>.

The whole paragraph would then read:

-- snip --

3.2.1.  Type

    When an entity-body is included with a message, the data type of that
    body is determined via the header fields Content-Type and Content-
    Encoding.  These define a two-layer, ordered encoding model:

      entity-body := Content-Encoding( Content-Type( data ) )

    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.  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.

    Content-Encoding may be used to indicate any additional content
    codings applied to the data, usually for the purpose of data
    compression, that are a property of the requested resource.  There is
    no default encoding.

    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").

-- snip --

Note that this does NOT contain any changes related to the feedback I 
sent in my previous mail.

BR, Julian (looking forward to get this issue from the table soon!)

Received on Saturday, 6 June 2009 10:07:03 UTC