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

On 2013/10/29 23:12, Julian Reschke wrote:
> 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:

>>> 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
>> 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?

I have to say that I don't consider this sentence to be useless.

As far as I remember, there are other specs (mail?) that say that 
text/plain is the default. So some implementers may be used to this, and 
apply it to http, too.

Also, while every natural language text has to assume that the reader 
uses a certain amount of rational thinking, specs are usually written 
with a somewhat reduced expectation in that respect, not because the 
average reader is particularly dumb, but because the consequences of 
interpreting something wrong are different than the consequences of 
getting something wrong when e.g. reading a novel.

So I don't see any reason for not keeping that sentence. Even if it 
doesn't help, it definitely doesn't hurt.

Regards,   Martin.

Received on Wednesday, 30 October 2013 08:53:47 UTC