Re: Content negotiation example needed.

On Sat, 11 Sep 1999, Nir Dagan wrote:

> At 06:21 PM 9/11/99 -0500, thatch@us.ibm.com wrote:
> >
> >I followed up the example that Max suggested (
> >http://www.w3.org/1999/08/smil-pressrelease), setting Netscape's language
> >preference to French (fr) and received the following message. Seems like
> >"negotiation" is a little strong a concept for whats going on.
> >
> >>Message when language set to French:

I think it would be useful to stress here that you should configure
into your browser the _list_ of languages that you are willing to
accept, not just the single one that seems to be implied by your
phrase "set to French".   (As I remarked in an earlier posting, there
is a quite approachable description in the Apache documentation, that
would I think be helpful irrespective of the server they are using,
for anyone who didn't yet want to tangle with the HTTP RFC itself:

  http://www.apache.org/docs/content-negotiation.html )

> >>Not Acceptable
> >>An appropriate representation of the requested resource
> >/1999/08/smil-pressrelease
> >>could not be found on this server.
> >>Available variants:
> >>   smil-pressrelease.html.en , type text/html, language en, charset
> iso-8859-1
> >>   smil-pressrelease.html.ja , type text/html, language ja, charset
> iso-2022-jp

> Sort of. According to RFC 2616 (HTTP/1.1 latest dratf standard)
> When a client specifies languages that are not available the server can do
> two different things:
> 1. return a 406 error message listing the avialable alternatives.
>    This is what the example does. HTTP does not specify exactly how to
> write the HTML.
>    In my view the returned document could be more human friendly.

This is a curious coincidence.  Exactly this point was raised on a
usenet WWW servers group a little while back, and, having thought it
over and tried a few things with Apache, I posted to the
comp.infosystems.www.servers.unix group only yesterday - before seeing
these exchanges on the mailing list - remarking on the unfriendly
appearance of this message and enquiring what mechanisms were
available in Apache, short of amending the source code, for improving
it.  If there is any positive response from the group, then it will
surely be interesting input to the current discussion.

> 2. The second option permitted by the spec. is to return the document in
> some default 

I hope I'm not being too pedantic here, but I don't see anything in
section 14.4 that explicitly permits a server to send a language
variant that the client has said they do not accept.  If they state no
language preference(s), then all are assumed equally acceptable to
them, which is not in dispute; but if they state any language
preference at all, then all languages not mentioned are assumed to
have a q=0, i.e to be unacceptable.  14.4 indeed says that
Accept-language is *similar* to Accept, and under the Accept header it
states clearly (quote):

   If an Accept header field is present,
   and if the server cannot send a response which is acceptable
   according to the combined Accept field value, then the server
   SHOULD send a 406 (not acceptable) response.
(end of quote)

So, this is not mandatory, but it is strongly recommended.

Thus it seems to be (please correct me if I am overlooking something)
that if a reader wants to get any language that is available, then
they either need to specify no preferences at all, or to add "*" to
their list with some low but non-zero "q" factor.

Be that as it may, the author or webmaster can achieve the effect with
Apache by providing (or symlinking to) a language variant which they
choose (this could meaningfully be the original language in which the
document was written), and nominating it as the generic
(non-language-specific) version.

Conversely, as I remarked, the user could achieve this by adding
"*;q=0.01" to their language preferences.

Speaking for myself, I'd find it more irritating to be sent a language
that I have, in effect, told my browser I can't read, than to be sent
a selection list, no matter how brusquely.  However, I am aware that
there will be far more readers out there who simply have no idea that
they should have configured their browser in this regard, so the
browser vendor will in all likelihood have already made the decision
for them, that they can only accept English.  (Or that they can only
accept the language that they used when setting up their OS).

> It is up to the content provider to decide, which option to take,
> what is the default language, and how to write the 406 error
> message.

I'd suggest that for most purposes, if the language negotiation has
failed to achieve a match, then a status 406 error page, albeit a more
friendly one than currently produced, with the selection menu, is the
optimum choice, as against sending them a language that they have (by
intention or by neglect) in effect indicated that they don't accept,
and remaining silent about the other languages that they could have
chosen.

However, if each page has explicit links to the other available
language variants, then the other option would seem to be entirely 
acceptable too, in practical terms, although as I read RFC2616, it is
actually going against that SHOULD clause.

IMHO of course, and usual caveats that this response was composed
on-the-hoof to the points raised, and may well contain errors: in case
of doubt the authoritative specifications need to be consulted.

all the best

Received on Sunday, 12 September 1999 08:50:57 UTC