Re: Accept-Charset support
Alan Barrett/DUB/Lotus wrote:
> I would like to get agreement on a definite proposal of how WWW browser
> vendors should request a server to send UTF-8.
You should have posted to http list long time ago.
> Browser vendors are not keen to send a very long list of character sets
> accepted due to the overhead. So I propose that the browser vendors pick
> one of the following...
Some browser vendors make it available to the user. This morning I was
definitely sick and tired of the BLINK thing and I decided to finally
take a look at Netscape's X resources. So, from today, my .Xdefaults file
has the following:
Netscape*httpAcceptLanguage: hr; q=1.0, en; q=0.8\r\nAccept-Charset:
<note>I split the second line because of mail.</note>
X resources are the last place I'd look for Accept-Language header, but
since it was there... Adding Accept-Charset is just a question of
imagination. Thank you, jwz.
Kill me if I know how to do it on Windowz. :)
> (1) If the user, though the UI, says they want to "Request Multi-Lingual
> Documents" then the browser should send:-
> However, I am worried that the Accept-Charset may not take a "*" wildcard
> parameter. Does anyone know?
HTTP 1.1 draft doesn't mention it. Even if it did, you didn't assign q
value to *, so it defaults to 1. So you didn't have to specify UTF-8.
And, as the current spec says, you didn't have to include accept-charset
at all. Omitting it means that all charsets are acceptable.
> What do people think about this suggestion? Will it work for servers? I am
> really keen to give servers a chance to return UTF-8. How do servers today
> return UTF-8 when Accept-Charset is not generally being sent to them?
If browsers don't send accept-charset and servers are able to return entity
body in different charsets, it would make cacheing impossible. There's no
point in including Vary: Accept-charset in the response, since proxy won't
get that header. Cute.
Why so many people in the cc field?
Life is a sexually transmitted disease.