Re: Comments (Part 2) on HTTP I-D Rev 05 (Adams #88, Accept-Language)

Jim Gettys:
>
>
>Similar to Adams #84:
>
>Glenn Adams notes:
>> 
>> 88. Section 14.4 does not contain language as found in other Accept-*
>> headers that recommends a 406 response in the case the server cannot
>> satisfy the request based on its variant set for the specified URI.
>> This precludes implementing client-side content negotiation along this
>> variance axis. Suggest adding the required language or a note
>> indicating why it is not present and what this means for client-side
>> negotiation.
>
>I believe this is an editorial bug from when 406 was introduced (or
>later, when some edit was applied).
>
>Again, guidance from content negotiation wizards soliticited.

This is not an editorial bug, it is intentional.  The idea behind it
is that accept-language states a preference rather than a hard software
restriction like the other accept headers.  Sending a 406 in stead of
something which cannot be by software is OK, sending a 406 in stead of
somehing not (explicitely) preferred is much less preferable.  This is
really a bit of a borderline case, one could also argue for a MAY send
406 here in the Accept-Language section.

The absence of language about 406 in 14.4 should not be interpreted as
blocking the implementation of client-side content negotiation on
language.  It does mean however that other mechanisms are needed on
top of HTTP (like TCN in rfc2295) if the client wants to express that
sending responses with unacceptable languages is absolutely forbidden.

On a related note: not only is the wording in Accept-language weaker
than that in the other accept headers, note also that the 406 language
in Accept: and Accept-Encoding: is stronger than that in
Accept-Charset.  Again this is intentional, and supposed to reflect
the probability that a response which is unacceptable according to the
given header can still be handled in some sub-optimal way.

In summary, HTTP/1.1 gives servers a lot of leeway in dealing with
situations where the accept headers cannot really be reconciled with
the available content.  This is intentional, and reflects the
inaccurary of the accept headers sent by historical (and still
current) client implementations.

>				- Jim

Received on Tuesday, 17 November 1998 10:29:48 UTC