Re: NEW ISSUE: content sniffing

On Wed, Apr 1, 2009 at 5:43 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>> It's relevant to any HTTP user agent that wishes to interoperate with
>> existing Web content.  For example, Imageshop (described earlier in
>> this thread) is not a browser but is interested in knowing when its
>> users expect an HTTP response to be treated as an image.
>
> No, it isn't relevant at all.

That's an extreme point of view.  The implementors of Imageshop
certainly want to know how to determine the MIME type of HTTP
responses they receive from the Web.

> What you are talking about is error recovery from the perspective
> of a particular type of casual user, not the protocol.

Without specifying how to determine the MIME type of HTTP responses,
implementor of user agents interested interoperating with existing Web
content will be forced to reverse engineer each other.  Undoubtedly,
they will make mistakes, and we'll be in an even worse position than
we are today.

> 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.

I agree that the spec should require that servers send the correct
MIME type in the Content-Type header.  No one is disputing this.

> The fact that different user agents deal with protocol violations in
> different ways is a good thing.

In this case, a diversity of sniffing algorithms is harmful both to
interoperatiblity and security.  We'd be much better off if all the
user agents that require sniffing used the same algorithm.

> The whole philosophy that protocol specs, as opposed to browser
> implementation specs, must describe the error-handling quirks
> of browsers is bankrupt.

I'm not proposing the spec describe the error handling quirks of
browsers.  I'm propose that the spec contain enough detail that
implementors of future user agents (if they are so inclined) can
determine the MIME type of HTTP responses from the Web.

> The correct way to interoperate with broken Web
> content is to display a very large error message that explains why
> it is broken.

Sadly, such user agents will not be as popular as those that just work.

> 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.

Be that as it may, as an implementor of a new user agent that would
like to interoperate with the Web, I would like to know how to
determine the MIME type of existing Web content.

> 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.

I am not interested in imposing browser behavior on other user agents.
 In fact, I think the spec should recommend against sniffing.

> 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.

These user agents are free to follow the recommended course of action
and not perform sniffing.  If they do require sniffing, then we're
much better off if they follow a standardized algorithm than if they
incorrectly reverse engineer other user agents.  Being explicit has
fewer failure modes that burying our heads in the sand.

> And I have no
> doubt that MSIE will change its sniffing behavior shortly after a
> few lawsuits demonstrate their stupidity.

You're entitled to that opinion, but I don't see content sniffing
going away anytime soon.

Adam

Received on Thursday, 2 April 2009 06:57:58 UTC