Re: update "Authoritative Metadata"/ contentTypeOverride-24 based on HTML 5 spec?

On Aug 17, 2007, at 1:51 PM, Dan Connolly wrote:

>       * Convince Web publishers to fix incorrectly labelled Web  
> content
>         and label it correctly in the future.
>       * Update the HTTP specification to match widely deployed
>         conventions captured in the HTML 5 draft.
>
> While the second option is unappealing, the first option seems
> infeasible.

It isn't infeasible.  It happens immediately after any such page
fails to render correctly, either in the form of an obvious error
message or a consistent save-as dialog, when that page is viewed
by the person authoring or maintaining the website.  The problem
is not the standard, it is not the algorithm, and it is not HTML.
The problem is the ridiculously lame excuses that some vendors make
in the face of the predominant unreliable browser, MSIE, failing
to note errors when a page is tested.

A single data format with identical message payload can have very
different meanings based on the media type (e.g., edit as generic
XML, view as hypertext, view as a speadsheet, or render graphical
charts).  That is fundamental to the Web architecture.
The proposal makes it impossible to view certain types as plain
text, even though that is a known mechanism on the Web for viewing
HTML source that should work with compliant browsers.  As a result,
it will break valid applications in order to support broken browsers.
To re-support those valid applications, we would have to define yet
another special type (a duplicate of text/plain) just to support
such behavior without suffering from broken sniffers that could be
easily fixed TODAY if a few companies weren't so unwilling to
display even the simplest of errors in the face of invalid content.

HTTP should not be changed to support broken and error-prone browsers.
Doing this in HTML5, instead of requiring that browsers display an
error message and disable active content, means that firewall
intermediaries will also have to follow this algorithm, spend
precious time sniffing the first 512 bytes of all content, and
reject unsafe sniffs that should be rejected at the client.

The Web needs to be able to support safety-critical information
systems, not just marketing fluff, and I assure you that nobody in
that crowd complains when their browser displays an error about an
incorrectly configured page.  The sniffing algorithm will comply
with HTTP if and only if the user is notified when an explicit
content-type != sniffed content type is perceived, and only if
the action in response to that error can be defined within the
browser configuration.  That places the sniffing behavior in
the realm of being robust in what is received, as opposed to strict
standards compliance, and may be tuned according to the needs of
the particular system in use.

....Roy

Received on Saturday, 18 August 2007 03:26:25 UTC