Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">

[Curt Sampson <cjs@example.com>]

On 2008-09-17 11:41 +0900 (Wed), Stephen J. Turnbull wrote:

>  > Rubbish. What "meaning of HTML document data" is this changing?
>  > 
>  >     <META http-equiv="Age" content="12">
> 
> Nobody's talking about any header other than Content-Type, here.

Excuse me, but that is *exactly* what I am talking about. Content-type
is just a weird special case of this stuff, with yet even more crud
piled on.

> You yourself have argued (and Edward has echoed) that asking the httpd
> to verify the claims in its Content-Type is too burdensome.  So the
> HTTP Content-Type header field is (in actual practice, and supported
> by theory) at best a hint.

So your claim is that, if I send an HTTP page as type "image/jpeg", the
browser should, rather than saying "this is a broken JPEG", dig around
and try to determine the content-type automatically?

This is probably in violation of the standard, and the technique is
certainly a classic source of security problems.

Basically, program your HTTP server to return correct content types, or
live with the consequences.

> If you don't want to deal with the inner protocol, don't use the
> Content-Type header.

And this is allowable in the standard? Just leave out "Content-type" and
have the client guess?

> I think it's much more sensible to *define* the outer Content-Type as
> a hint....

I think that's a very, very bad thing unless you're very specific about
exactly what may be encapsulated, and it's self-identifying. Again,
guessing at content interpretation on the part of the client has been a
source of security problems and exploits many times in the past.

>  > In the end, having a Content-type delivered by HTTP for whatever
>  > it's encapsulating makes as much sense as a Windows box interpreting
>  > any file ending in ".jpg" as a JPEG file,
> 
> Yeah, and we know how much havoc that has caused. :-(

Just what havoc, compared to not doing so?

>  > and a Mac interpreting any file whose resource fork says it's a
>  > JPEG file as a JPEG file. (Well strictly, JFIF files, but
>  > whatever.) If you're railing against all file file formats not
>  > being self-identifying, well, you may have a point.  But insisting
>  > that it's reasonable for some data to attempt modify information
>  > specified by a protocol unit encapsulating it is a path towards
>  > insanity,
> 
> It's not modifying that information...

It is, indeed. If the encapsulation says, "this chunk of data is
image/jpeg", and you chose to ignore that based on guessing at content,
then it is indeed modifying the interpretation of the document from what
the encpsulating protocol requested, which is what I meant.

> Obviously I believe that the right thing would be to amend the HTML
> standard to give precedence to the document.

That would also involve ammending the HTTP standard. But I'd be fine
with removing the ability of HTTP to specify an encoding for text/http
(or adding a new tag, text/http-internal-incoding, or whatever), and
then defining that as, "look in the document for the encoding." That's
far different from the general case of the situation now.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com