Re: NEW ISSUE: content sniffing

Adam,

> You're ignoring the reality of existing Web content.  To interoperate
> with existing Web content, a user agent must consider both the
> Content-Type headers and the content when determining the media type
> contained in a response.  To claim otherwise is fantasy.
>   
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.  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.  However, it is inappropriate to foist those 
"solutions" onto a community that is clearly saying "this is not an 
issue for our 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 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.

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.

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Friday, 3 April 2009 00:26:24 UTC