- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 05 Jun 2009 10:26:03 +0200
- To: Mark Nottingham <mnot@mnot.net>
- CC: "William A. Rowe, Jr." <wrowe@rowe-clan.net>, Mark Baker <distobj@acm.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>, Adam Barth <w3c@adambarth.com>
Mark Nottingham wrote:
> Given that, is the proposal acceptable as worded?
>
> On 05/06/2009, at 8:40 AM, Adam Barth wrote:
>
>> On Thu, Jun 4, 2009 at 2:43 PM, William A. Rowe, Jr.
>> <wrowe@rowe-clan.net> wrote:
>>> The first part 'should' read 'MUST', as Julian mentions below, the
>>> choice
>>> is in interpretation, not the value of the Content-Type header;
>>
>> This isn't workable. The content sniffing algorithm needs to
>> distinguish between an absent Content-Type header and a Content-Type
>> header with the value "application/octet-stream". Making this a MUST
>> requirement forces the algorithm to treat them the same.
>>
>> Adam
> ...
No, I think even "SHOULD" is too strong.
We want servers to provide Content-Type headers. But we also don't want
them to send *incorrect* headers. That is, if the server doesn't know,
or can't guess with any reliability, the best thing to do is *not* to
send the Content-Type header.
This, btw, is now at least *possible* with Apache httpd.
If we make the absence of Content-Type equivalent to sending
Content-Type: application/octet-stream, *and* recipients treat
application/octet-stream is recommended by
<http://greenbytes.de/tech/webdav/rfc2046.html#rfc.section.4.5.1>, then
sending no Content-Type becomes less plausible.
So, I think one way to fix this is to drop that sentence, making the
paragraph just:
"Note that neither the interpretation of the data type of a message nor
the behaviours caused by it are not defined by this specification; this
potentially includes examination of the content to override the
indicated type ("sniffing")."
BR, Julian
Received on Friday, 5 June 2009 08:26:47 UTC