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