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

Daniel Stenberg wrote:
> 
> On Thu, 3 Jul 2008, Justin James wrote:
> 
>> [...] a great many developers had no idea 
>> that they needed to change the Content-type at the code level to make 
>> this work. Content sniffing made life easier for these developers.
> 
> Uh, that doesn't make sense.
> 
> Sure, some scripts output wrong Content-Type. Then no browser can output 
> it correctly and thus you fix the server side.

Exactly.

> But, this system with bad Content-Type outputs still showing up nicely 
> only works if the client *already* have does this "sniffing" business 
> and thus they more or less encouraged the server-side hackers to remain 
> sloppy.
> 
> So this cannot have been a case where the browser adapted to how servers 
> work, since servers would hardly ever have worked this way if some 
> browsers didn't already support it...

Right.  For example, charset sniffing.  It's clear that MS has done the
community a huge disservice by including UTF-7 in the automatic sniffing,
given that it's now impossible to walk around every autodetection pitfall.
Sniffing UTF-7, far more than the base content-type, is the origin of my
grief against Microsoft.  (Well, that and the fact that it's very hard to
serve example files presented as text/plain for inspection when Microsoft
insists every user actually wants the results of that text file.)

If charsets were not sniffed, administrators would be 'forced' to correct
such flaws.  (They might be aware of the flaw in the first place, for that
matter.)  And should they leave the content type unstated, or without a
charset, it would then be perfectly reasonable for the content author to
describe the file in meta tags (once again, correctly).

> I find this "I promise this time I really mean that the type is what I 
> say" attribute hilariously funny.

:)

Received on Thursday, 3 July 2008 19:19:00 UTC