Microsoft's "I mean it" content-type parameter

At 18:17 +0200 3/07/08, Julian Reschke wrote:
>Dave Singer wrote:

Also, it might it be invoked by servers which report *no* Content-Type?


Well, that's totally ok. Servers that do not know the Content-Type
of a resource should not guess, which in turn allows the recipient
to sniff.
>>
>>but, as far as I can tell, there is no "unknown" content-type, is there?
>
>The way to signal "unknown" is not to send a Content-Type header at
>all. As far as I understand, this is what happens with httpd trunk
>when you set the DefaultType to "none".

or, it seems, "application/octet-stream". From HTTP 1.1:

Any HTTP/1.1 message containing an entity-body SHULD 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 SHULD
treat it as type "application/octet-stream".

It does seem as if sniffing when there is a content-type header is
flat-out forbidden. I.e. the presence of content-type was supposed
to serve *exactly* what the "I mean it" extension is doing

Next up: a server that always adds the "I mean it" attribute, even
when it doesn't, and the subsequent invention of the "No, really,
come on, you have to believe me, scout's honor, I really truly mean
it" extension.
--
David Singer
Apple/QuickTime

Dave Singer wrote:

Also, it might it be invoked by servers which report *no* Content-Type?

>>
>Well, that's totally ok. Servers that do not know the Content-Type of
>a resource should not guess, which in turn allows the recipient to sniff.

but, as far as I can tell, there is no "unknown" content-type, is there?

The way to signal "unknown" is not to send a Content-Type header at all.
As far as I understand, this is what happens with httpd trunk when you
set the DefaultType to "none".

BR, Julian

Dave Singer wrote:

Next up: a server that always adds the "I mean it" attribute, even when
it doesn't, and the subsequent invention of the "No, really, come on,
you have to believe me, scout's honor, I really truly mean it" extension.


course. That's why we usually do not define specific error recovery
in HTTPbis. First of all, mandating a very specific error recovery (1)
may not be the right thing for all use cases, (2) it blurs the boundary
between valid and invalid (if the behavior for invalid is mandatory,
where's the point in producing valid messages), and (3), as you said, in
the end you'll have to define error recovery for the error recovery

BR, Julian

Ian Hickson wrote:
Thu, 3 Jul 2008, Dave Singer wrote:
>Next up: a server that always adds the "I mean it" attribute, even when
>it doesn't, and the subsequent invention of the "No, really, come on,
>you have to believe me, scout's honor, I really truly mean it"
>extension.

This is exactly why this won't work. Sites will use this correctly, then
someone will set some default somewhere incorrectly, or copy and paste a
correct site somehow, or misunderstand a tutorial or something, and deploy
it without testing in IE8. And it will work fine in all the browsers


Well, only if the other UAs do not adopt the proposal.

I'm not saying they should (yet), but why wouldn't it work if all UAs
did the same thing here?

except IE8, an then IE8 will be patched to make this attribute trigger a
slightly different (and smaller) set of content-sniffing instead except
that the set won't be quite what was intended, because there will be some
bug, and then there will be sites that D test with this patched IE8, but
end up relying on this slightly different content sniffing

and ten years from now we'll have four different content sniffing modes
with four different ways of triggering it and the next generation will
look back at 2008 and wonder what we were thinking.


The way out of this mess is containment. We define a strict set of
Content-Type sniffing rules that are required to render the Web, and we
get the browsers to converge on only sniffing for those.


So you can get the browser vendors to converge on a precise set of
sniffing rules, but you can't get them to agree on an opt-out?

Sounds inconsistent to me.

BR, Julian

Julian Reschke wrote:

Sounds inconsistent to me.

Just for fun, MIME parts can have a Content-Type:

| Content-Type: text/html; (note unusual charset) charset=cp437

2.7.1 step 3 returns nothing

| Content-Type: text/html; charset= (take) "cp437" (that)

2.7.1 step 5 returns charset (take)

Frank

Frank Ellermann wrote:
Julian Reschke wrote:

>Sounds inconsistent to me.

Just for fun, MIME parts can have a Content-Type:

| Content-Type: text/html; (note unusual charset) charset=cp437

You mean "can have a comment"? Looking at RFC2616, Sections 14.17 and
3.7, that doesn't seem to be correct



BR, Julian

Julian Reschke wrote:

>| Content-Type: text/html; (note unusual charset) charset=cp437

You mean "can have a comment"? Looking at RFC2616, Sections 14.17
and 3.7, that doesn't seem to be correct

arrghh, those HTTP geeks. MIME parts are something in e-mail
or NetNews, often rendered by a Web browser if it's text/html ;-)

Frank

Ian Hickson wrote:
This is exactly why this won't work. Sites will use this correctly,
then someone will set some default somewhere incorrectly, or copy and
paste a correct site somehow, or misunderstand a tutorial or something,
and deploy it without testing in IE8. And it will work fine in all the
browsers except IE8, an then IE8 will be patched to make this attribute
trigger a slightly different (and smaller) set of content-sniffing

No.

The way out of this mess is containment. We define a strict set of
Content-Type sniffing rules that are required to render the Web, and we
get the browsers to converge on only sniffing for those.

Indeed. And we're providing a way for content providers to opt out of that mess.

-Chris Wilson