W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: NEW ISSUE: content sniffing

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 3 Apr 2009 01:46:55 +0000 (UTC)
To: Shane McCarron <shane@aptest.com>
Cc: Adam Barth <w3c@adambarth.com>, "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <Pine.LNX.4.62.0904030137400.25058@hixie.dreamhostps.com>
On Thu, 2 Apr 2009, Shane McCarron wrote:
> Roy was not "ignoring the reality of existing Web content".  He is 
> saying the same thing every other expert from this community has said - 
> that the error handling mechanism you are proposing to codify at the 
> *protocol* layer is not a protocol issue.

With all due respect, not "every other expert from this community" agrees 
with Roy. I don't, nor do many others.

Personally I think that whatever spec defines Content-Type should define 
how Content-Type works in reality. I would have no problem with HTTP 
itself not defining the Content-Type header at all. What I personally 
object to is the HTTP spec defining Content-Type in a way which is 
incompatible with billions of deployed resources.

> If you and others like you want to carefully define how your 
> applications deal with situations where the underlying layers have 
> provided you with mis-information, that is completely up to you.

Could we please not make this an "us vs them" discussion?

> However, it is inappropriate to foist those "solutions" onto a community 
> that is clearly saying "this is not an issue for our layer"!

By the same logic, it would be inappropriate to foist the solution 
currently in the HTTP specification onto a community that is clearly 
saying "this IS an issue for this layer".

> Moreover, it would be inappropriate to attempt to define your solution 
> in such a way that encourages the continued transmission of that 
> mis-information.

The current specification text, as it has stood since the dawn of the Web, 
has failed to discouraged the continued transmission of this 
mis-information. If we are trying to remove specification text that 
encourages the transmission of such mis-information, we should change the 

> The protocol provides mechanisms for servers to declare the type of a 
> payload. If some servers lie about it, that's their mistake.  We should 
> not be trying to insist that every endpoint deal with errors from the 
> broadcaster.  That way lies madness.  Look at it this way - if there 
> were billions of devices that could magically capture music out of the 
> air (call them radios), and hundreds or even thousands of sources for 
> that music, and tens of those sources were sending the music out in such 
> a way that the devices couldn't capture it... what would happen?  Would 
> all the devices get changed?  Absolutely not!  The sources would fix 
> themselves or they would disappear.  Either way, problem solved.

If there were billions of devices called radios, and of thousands of 
sources, tens of those sources were sending the music out in such a way 
that the devices couldn't capture it, but one of those sources was the 
incredibly popular BBC, then new devices called radios would immediately 
appear that DID handle those few incorrect sources. This is elementary 

> I am sure that the solution you are proposing works for the small subset 
> of the data and limited collection of data processors that you are 
> considering. In the greater collection of data that is the entire 
> Internet, and the greater collection of data processors that are all 
> agents that use HTTP, the solution just has no general place.  At least 
> that's my opinion.  I could be wrong.

I believe you are.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 3 April 2009 01:47:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:49 UTC