On Apr 1, 2009, at 4:48 PM, Adam Barth wrote:

No, it isn't relevant at all. If the purpose of the user agent is to find errors in metadata, then your prescribed sniffing requirements would obviously be false. A testing client (like MOMspider) is one such user agent.

What you are talking about is error recovery from the perspective of a particular type of casual user, not the protocol. The protocol is stating the communication from the sender. If the communication is false, the protocol is being violated and that violation is shown by failing to meet one of the protocol requirements. The fact that different user agents deal with protocol violations in different ways is a good thing.

The whole philosophy that protocol specs, as opposed to browser implementation specs, must describe the error-handling quirks of browsers is bankrupt. HTTP is not defined by browser reactions to HTTP messages. The correct way to interoperate with broken Web content is to display a very large error message that explains why it is broken. The fact that *some* HTTP user agents, notably the big browser vendors, choose not to display those errors in a usable way is a design choice for those user agents. It does not in any way change the semantics of the HTTP messages and the meaning of metadata within those messages.

The common browser behavior does not need to be standardized in HTTP because it is not common to the vast majority of user agent implementations, which far outnumber the general purpose browsers. It cannot be standardized in a way that would be safe for safety- critical environments such as health care, where failure to display the errors could very well result in serious injury or death. And I have no doubt that MSIE will change its sniffing behavior shortly after a few lawsuits demonstrate their stupidity.

....Roy