Re: Accept-Charset support
On Dec 4, 10:03am, Erik van der Poel wrote:
> 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
> first place.
It does require a round trip, but just to clarify Eriks (correct)
statement in case anyone drew (incorrect) conclusions: it need not
also require annother connection to be set up, because it is part of
HTTP/1.1 and thus there are persistent connections.
A more desirable scenario is that the server sends back what it reckons
to be the best thing, based on the request, but also indicates using
standard HTTP/1.1 headers the other variants that are available, with
the qs values. The browser can either use what it was given or select
one of the listed alternatives (and incur an additional round trip delay).
> How about using a more compact representation of Accept-Charset. E.g.
> bit masks corresponding to the number in the charset registry.
Do they have canonical numbers?
> would omit the "q" parameter, but I'm not sure this is needed in the
> Accept-Charset case anyway.
Since this would be a new representation, one could also add a
requirement that the charsets in such a binary representation are
sorted in decreasing order of q.
> Servers cannot send UTF-8 to clients unless they know that the client is
> capable of decoding it
which is indicated by the client sending an Accept-Charset. Quite.
Chris Lilley, W3C [ http://www.w3.org/ ]
Graphics and Fonts Guy The World Wide Web Consortium
http://www.w3.org/people/chris/ INRIA, Projet W3C
email@example.com 2004 Rt des Lucioles / BP 93
+33 (0)4 93 65 79 87 06902 Sophia Antipolis Cedex, France