Re: Beta: Charset attribute

On Fri, 8 Nov 2002, Terje Bless wrote:

> Lloyd Wood <> 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?



> The Content-Type may warrant a similar treatment, but probably not the
> doctype. I think... Maybe...


Received on Sunday, 10 November 2002 12:50:20 UTC