Re: several messages about content sniffing in HTML

On Feb 29, 2008, at 12:17 PM, Ian Hickson wrote:
> It's only necessary because the HTTP working group refuses to act in a
> responsible manner and actually specify how to write an  
> interoperable user
> agent that is both compatible with the Web and handles invalid  
> content. If
> HTTP defined how to do this, we wouldn't be stuck with defining it
> ourselves.

Ian, you haven't the faintest idea of how to write a specification that
will last beyond the current fad-of-the-day in implementations.  If HTTP
had been as foolish as HTML5 is being in regard to architectural  
decisions,
the entire Web would currently be owned by one vendor (pick any one).
All you are doing is ensuring that the future Web standard won't be
called HTML because future platforms won't be able to implement this
muck efficiently (unlike declarative HTML, which is inherently platform
and implementation neutral).

HTTP is an interface specification.  Anything it might say about how to
implement something that isn't defined by the interface would have to be
applicable to all potential implementations (unlike your opinion that  
HTML5
is defined by what four browsers think they can implement tomorrow).   
In this
case, it is far more interoperable for all implementations to explode  
upon
seeing multiple CT headers, since that is a security issue even if the
browsers react to it consistently.  But I can't spec it that way because
it isn't always practical to explode when the client is a small routine
within a larger real-time system.  All I can do is add a note to the
security sections about handling errors, which is what the HTTPbis WG
is going to do.

Browsers are only one type of HTTP client and the only one that has
persistent problems with implementation because some idiot decided that
all browsers had to be bugwards compatible with XMosaic.  The rest of  
the
world actually expects software to report errors so that they can be  
fixed
(and so that they don't become liable for misrepresenting lost data).
Browsers don't do that because they are immature software systems, not
because it is inherently better to hide errors.

> You are right that we could have picked the FF/Safari behaviour  
> instead of
> the IE/Opera behaviour, but you are wrong that it is ok for all the
> browsers to do their own thing here. What we want is interoperability.

That isn't interoperability.  Interoperability is when the server and  
client
agree on their interpretation of the message.  What you are talking  
about is
consistency in client implementation, whether or not it is  
interoperable with
a given server.

....Roy

Received on Friday, 29 February 2008 20:52:28 UTC