[links-list] Problem with forms?!
khim at sch57.msk.ru
Fri Jun 15 06:30:09 PDT 2001
On Fri, 15 Jun 2001, Mikulas Patocka wrote:
> > P.S. Hmm. At least this problem WAS discussed :-/ Last time I asked about
> > "HTTP over META" bug I was simply ignored (even if I attached patch to fix it).
> The patch is not very clean - so I won't accept it as it is.
May be - I do not know how to do this cleanly (I'm not exactly familiar
with links internals - I wanted to see web site more then anything).
> And the documents you referenced are not very clean. Please tell me how
> do you exactly expect it to work. What of these indicators should have
> what priority. Any other charset indicators?
> Content-Type in HTTP header
> Content-Charset in HTTP header
> Content-Type in META tag
> Content-Charset in META tag
> charset as a html attribute to META (http-equiv ? is it needed?) tag
Just like it showed above. But ONLY if attribute is there
1. IF Content-Type present and IF "charset=..." is there then that's
what should be used.
2. IF we do not know charset yet we need to look on Content-Charset
3. IF we do not know charset yet we need to look on Content-Type in META
4. IF we do not know charset yet we need to look on Content-Charset in META
5. IF we do not know charset yet we need to look on charset as a html
attribute to META
In fact ONLY 1. and 3. are really needed at all (correctly tuned server
SHOULD use "charset=..." attribute but there are quite a lot of public
server where you can only put "chraset=..." in text of html page; plus
local files). Why it's important to favor HTTP over META ? There are quite
a few servers where "recoding on the fly" is supported (at least in Russia).
In such case info from META tag will be WRONG but it's not easy to remove
this tag altogether (Netscape Composer and FrontPage using it while
editing local files and will put it back even if you'll remove tag). It's
EASY for server to recode text document on the fly. It's MUCH harder to
change document contents and strip meta tag. Content-Charset is NOT
stadard header and NOT used by wedely-spread editors thus how it's
handled is of no concern.
-- cut --
3.4.1 Missing Charset
Some HTTP/1.0 software has interpreted a Content-Type header without
charset parameter incorrectly to mean "recipient should guess." Senders
wishing to defeat this behavior MAY include a charset parameter even when
the charset is ISO-8859-1 and SHOULD do so when it is known that it will
not confuse the recipient.
Unfortunately, some older HTTP/1.0 clients did not deal properly
with an explicit charset parameter. HTTP/1.1 recipients MUST respect the
charset label provided by the sender; and those user agents that have a
provision to "guess" a charset MUST use the charset from the content-type
field if they support that charset, rather than the recipient's
preference, when initially displaying a document. See section 3.7.1.
3.7.1 Canonicalization and Text Defaults
The "charset" parameter is used with some media types to define the
character set (section 3.4) of the data. When no explicit charset
parameter is provided by the sender, media subtypes of the "text" type are
defined to have a default charset value of "ISO-8859-1" when received via
HTTP. Data in character sets other than "ISO-8859-1" or its subsets MUST
be labeled with an appropriate charset value. See section 3.4.1 for
-- cut --
links-list mailing list
links-list at appwatch.com
More information about the links-list