- From: Lloyd Wood <l.wood@eim.surrey.ac.uk>
- Date: Sun, 10 Nov 2002 17:50:02 +0000 (GMT)
- To: Terje Bless <link@pobox.com>
- cc: W3C Validator <www-validator@w3.org>
On Fri, 8 Nov 2002, Terje Bless wrote: > Lloyd Wood <l.wood@eim.surrey.ac.uk> wrote: > > >I ws thinking of this as a generic get-out for the Content-Type: META > >tag dilemma. A server should able to explicitly tell a client to obey > >the stuff in the page. > > In essence, this is what the various application/*+xml media types do; they > say "this is some kind of XML, dispatch on DOCTYPE and/or Namespace and use > XML heuristics to determine encoding". IOW, they've moved the type and > encoding determination in-band instead of relying on the established > out-of-band methods provided by HTTP (and several decades worth of > experience from other systems (email and MIME chief among them)). You're right, +xml is all screwy. Better than Content-Type: text/whatever-it-says-dude would be to simply leave the Content-Type: field out altogether, on the grounds that if you're going to start being stupid, broken and in-band you may as well be completely stupid, broken and in-band. > And frankly, if you can force the use of text/whatever-it-says-dude, you > could equally well set the _correct_ information in the first place. so webservers should leave out Content-Type: entirely if there's any doubt that they're not serving out the right thing. Except that to check they'd have to do in-band checks themselves... > But for an uploaded file, at least the character set will _never_ bear any > kind of relation to what it /would/ be when served from a web server (this > much has been mentioned before on the list, BTW). Perhaps the most > constructive way to deal with it is to _always_ require the charset > "override" to be set for file uploads? definitely. L. > The Content-Type may warrant a similar treatment, but probably not the > doctype. I think... Maybe... <http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@ee.surrey.ac.uk>
Received on Sunday, 10 November 2002 12:50:20 UTC