Content-type META tag paradox?

[Harlan Messinger]

Why would anyone ever have expected a content-type META tag to be effective
at all? Is it because someone was misled by the happenstance the letters of
the alphabet, the digits, and the characters {< > / ; , " ' =} happen to be
at the same locations in several particular common encodings (US-ASCII,
ISO-8859-1, etc.)?

Even assuming that these characters are always in the same locations, before
it can find my META tag in the first place, the UA has to make an *initial*
assumption as to whether the document is even 8-bit versus 16-bit.

Let's say I were perverse enough to save my HTML document using an editor
that encodes text as EBCDIC. How would the UA figure out not only where my
META tag is, but where ANYTHING is?

And that just addreses the encoding. How about the content-type? What if I
were twisted enough to tell the UA, which has been assuming that my document
is an HTML text document just long enough to reach and parse my META tag in
the first place, that the document is really text/plain? (In that case,
would it start over from the beginning based on text/plain, this time not
doing any parsing at all, and therefore not finding a META tag at all, and
therefore not finding an override for the default supposition of text/html,
and therefore AGAIN starting from the beginning and parsing the document as
HTML, and then finding the META tag and realizing the document is
text/plain, and starting all over again based on that assumption, and then
.....) Or image/gif?

So I'm just curious how the content-type META tag got into the spec in the
first place. It seems to defy logic.

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.

[Pierre Goiffon]

"Harlan Messinger" <h.*********@co mcast.net> a écrit dans le message de
news:c5******** ****@ID-114100.news.uni-berlin.de

Let's say I were perverse enough to save my HTML document using an
editor that encodes text as EBCDIC. How would the UA figure out not
only where my META tag is, but where ANYTHING is?

I can't understand - HTML must use only us-ascii characters, either do the
content type attributes values...
Hu ?

[Pierre Goiffon]

"Harlan Messinger" <h.*********@co mcast.net> a écrit dans le message de
news:c5******** ****@ID-114100.news.uni-berlin.de

Let's say I were perverse enough to save my HTML document using an
editor that encodes text as EBCDIC. How would the UA figure out not
only where my META tag is, but where ANYTHING is?

I can't understand - HTML must use only us-ascii characters, either do the
content type attributes values...
Hu ?

[Jim Dabell]

Harlan Messinger wrote:
[snip]

And that just addreses the encoding. How about the content-type? What if I
were twisted enough to tell the UA, which has been assuming that my
document is an HTML text document just long enough to reach and parse my
META tag in the first place, that the document is really text/plain? (In
that case, would it start over from the beginning based on text/plain,
this time not doing any parsing at all, and therefore not finding a META
tag at all, and therefore not finding an override for the default
supposition of text/html, and therefore AGAIN starting from the beginning
and parsing the document as HTML, and then finding the META tag and
realizing the document is text/plain, and starting all over again based on
that assumption, and then ....) Or image/gif?
The HTTP 1.1 specification makes it clear that the Content-Type header
should take precedence over anything that may be in the response body:

"If and only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its content
and/or the name extension(s) of the URI used to identify the resource."

-- <URL:http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7. 2.1>

So if the HTTP headers say it's text/plain, text/plain it is (unless you use
a browser that violates the HTTP 1.1 specification).

So I'm just curious how the content-type META tag got into the spec in the
first place. It seems to defy logic.

According to the HTML 4.01 specification, <meta> elements with http-equiv
attributes are designed to be parsed by the server and converted to proper
HTTP headers. In reality, this is usually impractical, and browsers
started to pay attention themselves a long time ago. As you've said, this
can lead to some stupid results.

"HTTP servers may use the property name specified by the http-equiv
attribute to create an [RFC822]-style header in the HTTP response."

-- <URL:http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.2>

As far as the paradox of figuring out the character encoding goes, the way I
understand it is that if the HTTP headers don't indicate the encoding, it
defaults to US-ASCII, and when it gets to the relevant <meta> element, the
browser has the option of starting again with that character encoding.
This means that as long as you use a superset of US-ASCII, it will "work".

I believe the rules for default character encodings change when you start
talking about XHTML (plus you have to throw the XML prolog into the mix).
Also remember that a browser can (reliably?) detect UTF-16 by the BOM.

You'll probably want to read through this lot if you haven't already:

<URL:http://ppewww.ph.gla.a c.uk/~flavell/charset/>
--
Jim Dabell

[Jim Dabell]

Harlan Messinger wrote:
[snip]

And that just addreses the encoding. How about the content-type? What if I
were twisted enough to tell the UA, which has been assuming that my
document is an HTML text document just long enough to reach and parse my
META tag in the first place, that the document is really text/plain? (In
that case, would it start over from the beginning based on text/plain,
this time not doing any parsing at all, and therefore not finding a META
tag at all, and therefore not finding an override for the default
supposition of text/html, and therefore AGAIN starting from the beginning
and parsing the document as HTML, and then finding the META tag and
realizing the document is text/plain, and starting all over again based on
that assumption, and then ....) Or image/gif?
The HTTP 1.1 specification makes it clear that the Content-Type header
should take precedence over anything that may be in the response body:

"If and only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its content
and/or the name extension(s) of the URI used to identify the resource."

-- <URL:http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7. 2.1>

So if the HTTP headers say it's text/plain, text/plain it is (unless you use
a browser that violates the HTTP 1.1 specification).

So I'm just curious how the content-type META tag got into the spec in the
first place. It seems to defy logic.

According to the HTML 4.01 specification, <meta> elements with http-equiv
attributes are designed to be parsed by the server and converted to proper
HTTP headers. In reality, this is usually impractical, and browsers
started to pay attention themselves a long time ago. As you've said, this
can lead to some stupid results.

"HTTP servers may use the property name specified by the http-equiv
attribute to create an [RFC822]-style header in the HTTP response."

-- <URL:http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.2>

As far as the paradox of figuring out the character encoding goes, the way I
understand it is that if the HTTP headers don't indicate the encoding, it
defaults to US-ASCII, and when it gets to the relevant <meta> element, the
browser has the option of starting again with that character encoding.
This means that as long as you use a superset of US-ASCII, it will "work".

I believe the rules for default character encodings change when you start
talking about XHTML (plus you have to throw the XML prolog into the mix).
Also remember that a browser can (reliably?) detect UTF-16 by the BOM.

You'll probably want to read through this lot if you haven't already:

<URL:http://ppewww.ph.gla.a c.uk/~flavell/charset/>
--
Jim Dabell

[Pierre Goiffon]

"Jim Dabell" <ji********@jim dabell.com> a écrit dans le message de
news:7K******** ************@gi ganews.com

According to the HTML 4.01 specification, <meta> elements with
http-equiv attributes are designed to be parsed by the server and
converted to proper HTTP headers.
The rec says "may", so this is not mandatory. By the way, if anyone could
post a list of HTTPd that really retrieve the HTML content-type META value
and sends it in the response http header, I would be very glad 8) Can't find
this information anywhere since years
In reality, this is usually impractical, and browsers
started to pay attention themselves a long time ago.

I didn't understand, can you please explain ?

[Pierre Goiffon]

"Jim Dabell" <ji********@jim dabell.com> a écrit dans le message de
news:7K******** ************@gi ganews.com

According to the HTML 4.01 specification, <meta> elements with
http-equiv attributes are designed to be parsed by the server and
converted to proper HTTP headers.
The rec says "may", so this is not mandatory. By the way, if anyone could
post a list of HTTPd that really retrieve the HTML content-type META value
and sends it in the response http header, I would be very glad 8) Can't find
this information anywhere since years
In reality, this is usually impractical, and browsers
started to pay attention themselves a long time ago.

I didn't understand, can you please explain ?

[Jukka K. Korpela]

"Pierre Goiffon" <pg******@nowhe re.invalid> wrote:

Let's say I were perverse enough to save my HTML document using an
editor that encodes text as EBCDIC. How would the UA figure out not
only where my META tag is, but where ANYTHING is?

I can't understand - HTML must use only us-ascii characters, either
do the content type attributes values...

Where did you get such ideas?

HTML surely needs some characters that belong to the Ascii repertoire,
such as "<" and "a". But there is no requirement that they be represented
in the Ascii encoding.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Jukka K. Korpela]

"Pierre Goiffon" <pg******@nowhe re.invalid> wrote:

Let's say I were perverse enough to save my HTML document using an
editor that encodes text as EBCDIC. How would the UA figure out not
only where my META tag is, but where ANYTHING is?

I can't understand - HTML must use only us-ascii characters, either
do the content type attributes values...

Where did you get such ideas?

HTML surely needs some characters that belong to the Ascii repertoire,
such as "<" and "a". But there is no requirement that they be represented
in the Ascii encoding.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Pierre Goiffon]

"Jukka K. Korpela" <jk******@cs.tu t.fi> a écrit dans le message de
news:Xn******** *************** ******@193.229. 0.31

I can't understand - HTML must use only us-ascii characters, either
do the content type attributes values...

Where did you get such ideas?

I was talking about HTML code, not about contents ! Tags like <html>,
<head>, etc
Contents in a HTML document needs of course all the meaning to contains
international characters, from european to chinese.

I was pretty sure to have read that HTML code is only composed of us-ascii
characters but... can't find out that somewhere now :(
If this is confirmed, as said Jim Dabell just below, a browser that
retrieves a document with no http charset information could I guess easyly
gets the html content-type meta value by parsing the document in us-ascii.
In a well formed document, all the structured delimiter for that meta
(doctype, html, head) would be indeed encoded using us-ascii only.

Did I explained it much clearer ? Sorry but it's just difficult for me to
express in english which is not at all my mother tongue.