Re: Accept-Charset support
> Browser vendors are not keen to send a very long list of character sets
> accepted due to the overhead.
Right. This is one concern that keeps coming up over here at Netscape.
At the Sevilla conference, Larry Masinter mentioned "transparent content
negotiation", where it is apparently possible for the client to first
indicate a willingness to negotiate, and the server could respond with a
list of choices, from which the client makes a choice.
This, however, requires another round-trip to the server and back, and
might be even more expensive than just sending all the charsets in the
How about using a more compact representation of Accept-Charset. E.g.
bit masks corresponding to the number in the charset registry. This
would omit the "q" parameter, but I'm not sure this is needed in the
Accept-Charset case anyway. (It's probably needed for Accept-Language.)
> (1) If the user, though the UI, says they want to "Request Multi-Lingual
> Documents" then the browser should send:-
I don't think we should have UI for the Accept-Charset. Think about
novice users. Will they understand it?
> 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?
Servers cannot send UTF-8 to clients unless they know that the client is
capable of decoding it or there is a large critical mass of browsers in
the installed base that is known to be capable of decoding UTF-8.