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.
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. 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. 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).
Regards,
S. Moonesamy