Mailing List Archive
tlug.jp Mailing List tlug archive tlug Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- Date: Wed, 17 Sep 2008 14:08:48 +0900
- From: Curt Sampson <cjs@example.com>
- Subject: Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- References: <48C9F1C4.10404@bebear.net> <878wtx7tkq.fsf@xemacs.org> <20080912073930.GA8935@lucky.cynic.net> <8763p17ms6.fsf@xemacs.org> <20080912094652.GD8935@lucky.cynic.net> <873ak27pfe.fsf@xemacs.org> <20080915025127.GB1369@lucky.cynic.net> <87y71s66h2.fsf@xemacs.org> <20080916083716.GI18304@lucky.cynic.net> <87ej3j5wab.fsf@xemacs.org>
- User-agent: Mutt/1.5.17 (2007-11-01)
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
- Follow-Ups:
- Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- From: Edward Middleton
- Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- From: Stephen J. Turnbull
- References:
- Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- From: Edward Middleton
- Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- From: Stephen J. Turnbull
- Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- From: Curt Sampson
- Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- From: Stephen J. Turnbull
- Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- From: Curt Sampson
- Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- From: Stephen J. Turnbull
- Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- From: Curt Sampson
- Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- From: Stephen J. Turnbull
- Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- From: Curt Sampson
- Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- From: Stephen J. Turnbull
Home | Main Index | Thread Index
- Prev by Date: Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- Next by Date: Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- Previous by thread: Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- Next by thread: Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links