On 2013-10-29 14:26, S Moonesamy wrote:
Hi Julian,
At 09:06 28-10-2013, Julian Reschke wrote:
On 2013-10-28 09:07, S Moonesamy wrote:
(which expired ~2 years ago)
I guess that the working group gave up. Please note that I did not
suggest adding a reference.
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.
The 'If the media type remains unknown, the recipient SHOULD treat it as
type "application/octet-stream' from RFC 2616 is not in
draft-ietf-httpbis-p2-semantics-24.
I consider that sentence to be useless - if I can't detect the type,
what else but "treating as arbitrary data" is left as an option anyway?
The issue is the "or examine the data to determine its type". I'll
comment about the text (Section 3.1.1.5) again. The server has to
generate a Content-Type header field unless the media type is unknown.
Yes.
There is then a RFC 2119 "may" which is applicable when the (previous)
RFC 2119 "should" cannot be applied. My reading of the "may" is that
the usage is not entirely correct. I am not raising that as an issue.
I still don't get what the issue is :-)
The issue is whether there is a security problem and whether there is
adequate discussion of it (e.g. it is discussed in a Security
Considerations section).
The subsequent text is:
"In practice, resource owners do not always properly configure their
origin server to provide the correct Content-Type for a given
representation, with the result that some clients will examine a
payload's content and override the specified type. Clients that do so
risk drawing incorrect conclusions, which might expose additional
security risks (e.g., "privilege escalation"). Furthermore, it is
impossible to determine the sender's intent by examining the data
format: many data formats match multiple media types that differ only in
processing semantics. Implementers are encouraged to provide a means of
disabling such "content sniffing" when it is used."
Do you think this is insufficient, or that it needs to move to a
different part of the spec?
Best regards, Julian