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

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

Received on Monday, 28 October 2013 16:07:30 UTC