W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

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

From: S Moonesamy <sm+ietf@elandsys.com>
Date: Tue, 29 Oct 2013 06:26:34 -0700
Message-Id: <>
To: Julian Reschke <julian.reschke@gmx.de>, apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org
Cc: iesg@ietf.org, ietf-http-wg@w3.org, ietf@ietf.org
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 
>>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 

The issue is the "or examine the data to determine its type".  I'll 
comment about the text (Section 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).

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC