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

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

Received on Tuesday, 29 October 2013 13:50:39 UTC