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

Robert Collins wrote:
> On Wed, 2008-07-02 at 22:52 +0200, Julian Reschke wrote:
>>
>> Let's ignore the issue of inventing a new media type parameter for all 
>> new media types for a moment...

And ignore the fact that the content may not be proxied properly?  I think
that's a pretty silly detail to ignore.

>> It's good that MS recognizes that content-type-sniffing may be bad and 
>> that they are doing something about it. But is this really the right 
>> approach?
> 
> If they assume that fixing all the bust clients they have been shipping
> for years is infeasible, then I think they would have concluded its the
> right way.

Of course, this repairs all the bust clients no more effectively than
changing their behavior to conform to RFC2616 in the first place.

> I think its bogus - it requires every web site author in existence to
> change their site to fix a defect in MSIE. Thats got to be harder to
> deploy than just a hotfix to MSIE to not sniff at all. 'Sorry, bad idea,
> fixed in hotfix #12345.'

Well, at least every administrator.

I find this statement from the blog very telling;

"For instance, if Internet Explorer finds HTML content in a file delivered
with the HTTP response header Content-Type: text/plain, IE determines that
the content should be rendered as HTML. Because of the number of legacy
servers on the web (e.g. those that serve all files as text/plain)
MIME-sniffing is an important compatibility feature."

It would be very fun to see the example they cite, I sincerely doubt they
exist to any legitimate extent today.  Our friends crawling the web could
probably give us hard numbers.  I suspect the short history goes;

  * some folks start serving files over http:, associate .html with text/html

  * 1000's download ms authoring tools to create default.htm files

  * 100's uploading to these "ancient" servers discover they render as either
    binary/octet-stream or text/plain

  * MS fixes their client to display .htm files as html

Interestingly, they don't work around the fact that all of these servers are
also configured to serve index.html and not default.htm.  If they relied on
the administrators to fix one side of the coin...

Of course I don't think the example tells the story.  Embedded client side
execution of a host of MS formats further poisoned the ecosystem, which
was far more important to Microsoft than ensuring text/plain renders as
html.  Nobel purposes, for a utopian web of trustworthy content providers.

This makes no more sense than their lifting Content-Disposition into http,
but there you go, it's there.  Until more major MS customers move entirely
to Firefox or other alternatives, I don't anticipate this patchwork approach
changing.  And few content providers are so lucky as to dictate their
browser client.

It certainly hasn't enjoyed peer scrutiny, though, and I doubt MS will ask
for it.  They are likely to get it in the blogosphere, however.

Received on Thursday, 3 July 2008 00:20:43 UTC