ietf
[Top] [All Lists]

content inspection in absence of media type, was: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p2-semantics-24

2013-10-28 11:08:08
On 2013-10-28 09:07, S Moonesamy wrote:
...
Major Issues:

In Section 3.1.1.5:

   'If a Content-Type header field is not present, the recipient MAY
    either assume a media type of "application/octet-stream" ([RFC2046],
    Section 4.5.1) or examine the data to determine its type.'

According to RFC 2046, the "octet-stream" subtype is used to indicate
that a body contains arbitrary data.  The RFC 2119 "may" leaves it to
the implementor to make an assumption.  I suggest turning this into a
recommendation so that the assumption is clear to the implementor.
There is a discussion of MIME sniffing in
draft-ietf-websec-mime-sniff-03.  There has been discussion about MIME

(which expired ~2 years ago)

or Content sniffing over the years.  I am aware that some browsers do
MIME sniffing.  I understand that it is sometimes needed to make the Web
work.  However, it can lead to security vulnerabilities.  The paragraph
which follows the one quoted above discusses about that.  I listed this
as a major issue for the attention of the Applications Area Directors.
...

Could you clarify what exactly the issue is?

RFC 2616 said (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.7.2.1.p.4>):

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field 
defining the media type of that body. 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 isn't that different.

Best regards, Julian

<Prev in Thread] Current Thread [Next in Thread>