- 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>
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 spec! > 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 capitalism. > 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