14.2 Accept-Charset

   The Accept-Charset request-header field can be used to indicate what
   character sets are acceptable for the response. This field allows
   clients capable of understanding more comprehensive or special-
   purpose character sets to signal that capability to a server which is
   capable of representing documents in those character sets. The ISO-
   8859-1 character set can be assumed to be acceptable to all user
   agents.

          Accept-Charset = "Accept-Charset" ":"
                    1#( charset [ ";" "q" "=" qvalue ] )

   Character set values are described in section 3.4. Each charset may
   be given an associated quality value which represents the user's
   preference for that charset. The default value is q=1. An example is

          Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

   If no Accept-Charset header is present, the default is that any
   character set is acceptable. If an Accept-Charset header is present,
   and if the server cannot send a response which is acceptable
   according to the Accept-Charset header, then the server SHOULD send
   an error response with the 406 (not acceptable) status code, though
   the sending of an unacceptable response is also allowed.

14.3 Accept-Encoding

   The Accept-Encoding request-header field is similar to Accept, but
   restricts the content-coding values (section 14.12) which are
   acceptable in the response.

          Accept-Encoding  = "Accept-Encoding" ":"
                                    #( content-coding )

   An example of its use is

          Accept-Encoding: compress, gzip

   If no Accept-Encoding header is present in a request, the server MAY
   assume that the client will accept any content coding. If an Accept-
   Encoding header is present, and if the server cannot send a response
   which is acceptable according to the Accept-Encoding header, then the
   server SHOULD send an error response with the 406 (Not Acceptable)
   status code.




Fielding, et. al.           Standards Track                    [Page 97]

RFC 2068                        HTTP/1.1                    January 1997


   An empty Accept-Encoding value indicates none are acceptable.

14.4 Accept-Language

   The Accept-Language request-header field is similar to Accept, but
   restricts the set of natural languages that are preferred as a
   response to the request.

          Accept-Language = "Accept-Language" ":"
                            1#( language-range [ ";" "q" "=" qvalue ] )

          language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

   Each language-range MAY be given an associated quality value which
   represents an estimate of the user's preference for the languages
   specified by that range. The quality value defaults to "q=1". For
   example,

          Accept-Language: da, en-gb;q=0.8, en;q=0.7

   would mean: "I prefer Danish, but will accept British English and
   other types of English." A language-range matches a language-tag if
   it exactly equals the tag, or if it exactly equals a prefix of the
   tag such that the first tag character following the prefix is "-".
   The special range "*", if present in the Accept-Language field,
   matches every tag not matched by any other range present in the
   Accept-Language field.

     Note: This use of a prefix matching rule does not imply that
     language tags are assigned to languages in such a way that it is
     always true that if a user understands a language with a certain
     tag, then this user will also understand all languages with tags
     for which this tag is a prefix. The prefix rule simply allows the
     use of prefix tags if this is the case.

   The language quality factor assigned to a language-tag by the
   Accept-Language field is the quality value of the longest language-
   range in the field that matches the language-tag. If no language-
   range in the field matches the tag, the language quality factor
   assigned is 0. If no Accept-Language header is present in the
   request, the server SHOULD assume that all languages are equally
   acceptable. If an Accept-Language header is present, then all
   languages which are assigned a quality factor greater than 0 are
   acceptable.

   It may be contrary to the privacy expectations of the user to send an
   Accept-Language header with the complete linguistic preferences of
   the user in every request. For a discussion of this issue, see



Fielding, et. al.           Standards Track                    [Page 98]

RFC 2068                        HTTP/1.1                    January 1997


   section 15.7.

     Note: As intelligibility is highly dependent on the individual
     user, it is recommended that client applications make the choice of
     linguistic preference available to the user. If the choice is not
     made available, then the Accept-Language header field must not be
     given in the request.