rfc2295.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,667 行 · 第 1/5 页

   A feature list element yields its true-improvement factor if the
   corresponding feature predicate is true, or if at least one element
   of the corresponding fpred-bag is true. The element yields its
   false-degradation factor otherwise.





Holtman & Mutz                Experimental                     [Page 24]

RFC 2295            Transparent Content Negotiation           March 1998


7  Remote variant selection algorithms

   A remote variant selection algorithm is a standardized algorithm by
   which a server can choose a best variant on behalf of a negotiating
   user agent.  The use of a remote algorithm can speed up the
   negotiation process by eliminating a request-response round trip.

   A remote algorithm typically computes whether the Accept- headers in
   the request contain sufficient information to allow a choice, and if
   so, which variant is the best variant.  This specification does not
   define any remote algorithms, but does define a mechanism to
   negotiate on the use of such algorithms.

7.1 Version numbers

   A version numbering scheme is used to distinguish between different
   remote variant selection algorithms.

      rvsa-version = major "." minor

      major = 1*4DIGIT
      minor = 1*4DIGIT

   An algorithm with the version number X.Y, with Y>0, MUST be downwards
   compatible with all algorithms from X.0 up to X.Y.  Downwards
   compatibility means that, if supplied with the same information, the
   newer algorithm MUST make the same choice, or a better choice, as the
   old algorithm.  There are no compatibility requirements between
   algorithms with different major version numbers.

8  Content negotiation status codes and headers

   This specification adds one new HTTP status code, and introduces six
   new HTTP headers.  It also extends the semantics of an existing
   HTTP/1.1 header.

8.1 506 Variant Also Negotiates

   The 506 status code indicates that the server has an internal
   configuration error: the chosen variant resource is configured to
   engage in transparent content negotiation itself, and is therefore
   not a proper end point in the negotiation process.









Holtman & Mutz                Experimental                     [Page 25]

RFC 2295            Transparent Content Negotiation           March 1998


8.2 Accept-Features

   The Accept-Features request header can be used by a user agent to
   give information about the presence or absence of certain features in
   the feature set of the current request.  Servers can use this
   information when running a remote variant selection algorithm.

      Note: the name `Accept-Features' for this header was chosen
      because of symmetry considerations with other Accept- headers,
      even though the Accept-Features header will generally not contain
      an exhaustive list of features which are somehow `accepted'.  A
      more accurate name of this header would have been `Feature-Set-
      Info'.

       Accept-Features = "Accept-Features" ":"
                   #( feature-expr *( ";" feature-extension ) )

       feature-expr = [ "!" ] ftag
                    | ftag ( "=" | "!=" ) tag-value
                    | ftag "=" "{" tag-value "}"
                    | "*"

       feature-extension = token [ "=" ( token | quoted-string ) ]

   No feature extensions are defined in this specification.  An example
   is:

       Accept-Features: blex, !blebber, colordepth={5}, !screenwidth,
                  paper = A4, paper!="A2", x-version=104, *

   The different feature expressions have the following meaning:

      ftag       ftag is present

      !ftag      ftag is absent

      ftag=V     ftag is present with the value V

      ftag!=V    ftag is present, but not with the value V

      ftag={V}   ftag is present with the value V, and not with any
                 other values

      *          the expressions in this header do not fully describe
                 the feature set: feature tags not mentioned in this
                 header may also be present, and, except for the case
                 ftag={V}, tags may be present with more values than
                 mentioned.



Holtman & Mutz                Experimental                     [Page 26]

RFC 2295            Transparent Content Negotiation           March 1998


   Absence of the Accept-Features header in a request is equivalent to
   the inclusion of

      Accept-Features: *

   By using the Accept-Features header, a remote variant selection
   algorithm can sometimes determine the truth value of a feature
   predicate on behalf of the user agent.  For example, with the header

       Accept-Features: blex, !blebber, colordepth={5}, !screenwidth,
                  paper = A4, paper!="A2", x-version=104, *

   the algorithm can determine that the following predicates are true:

       blex, colordepth=[4-], colordepth!=6, colordepth, !screenwidth,
       paper=A4, colordepth=[4-6]

   and that the following predicates are false:

       !blex, blebber, colordepth=6, colordepth=foo, !colordepth,
       screenwidth, screenwidth=640, screenwidth!=640,

   but the truth value of the following predicates cannot be
   determined:

       UA-media=stationary, UA-media!=screen, paper!=a0,
       x-version=[100-300], x-version=[200-300], x-version=99,
       UA-media=screen, paper=A0, paper=a4, x-version=[100-199], wuxta

8.3 Alternates

   The Alternates response header is used to convey the list of variants
   bound to a negotiable resource.  This list can also include
   directives for any content negotiation process.  If a response from a
   transparently negotiable resource includes an Alternates header, this
   header MUST contain the complete variant list bound to the negotiable
   resource.  Responses from resources which do not support transparent
   content negotiation MAY also use Alternates headers.

       Alternates = "Alternates" ":" variant-list

       variant-list = 1#( variant-description
                        | fallback-variant
                        | list-directive )

       fallback-variant = "{" <"> URI <"> "}"

       list-directive = ( "proxy-rvsa" "=" <"> 0#rvsa-version <"> )



Holtman & Mutz                Experimental                     [Page 27]

RFC 2295            Transparent Content Negotiation           March 1998


                        | extension-list-directive

       extension-list-directive =
                        token [ "=" ( token | quoted-string ) ]

   An example is

     Alternates: {"paper.1" 0.9 {type text/html} {language en}},
                 {"paper.2" 0.7 {type text/html} {language fr}},
                 {"paper.3" 1.0 {type application/postscript}
                     {language en}},
                 proxy-rvsa="1.0, 2.5"

   Any relative URI specified in a variant-description or fallback-
   variant field is relative to the request-URI.  Only one fallback-
   variant field may be present.  If the variant selection algorithm of
   the user agent finds that all described variants are unacceptable,
   then it SHOULD choose the fallback variant, if present, as the best
   variant.  If the user agent computes the overall quality values of
   the described variants, and finds that several variants share the
   highest value, then the first variant with this value in the list
   SHOULD be chosen as the best variant.

   The proxy-rvsa directive restricts the use of remote variant
   selection algorithms by proxies. If present, a proxy MUST ONLY use
   algorithms which have one of the version numbers listed, or have the
   same major version number and a higher minor version number as one of
   the versions listed.  Any restrictions set by proxy-rvsa come on top
   of the restrictions set by the user agent in the Negotiate request
   header.  The directive proxy-rvsa="" will disable variant selection
   by proxies entirely.  Clients SHOULD ignore all extension-list-
   directives they do not understand.

   A variant list may contain multiple differing descriptions of the
   same variant.  This can be convenient if the variant uses conditional
   rendering constructs, or if the variant resource returns multiple
   representations using a multipart media type.

8.4 Negotiate

   The Negotiate request header can contain directives for any content
   negotiation process initiated by the request.

      Negotiate = "Negotiate" ":" 1#negotiate-directive

      negotiate-directive = "trans"
                          | "vlist"
                          | "guess-small"



Holtman & Mutz                Experimental                     [Page 28]

RFC 2295            Transparent Content Negotiation           March 1998


                          | rvsa-version
                          | "*"
                          | negotiate-extension

      negotiate-extension = token [ "=" token ]

   Examples are

      Negotiate: 1.0, 2.5
      Negotiate: *

   The negotiate directives have the following meaning

      "trans"
        The user agent supports transparent content negotiation for
        the current request.

      "vlist"
        The user agent requests that any transparently negotiated
        response for the current request includes an Alternates
        header with the variant list bound to the negotiable resource.
        Implies "trans".

      "guess-small"
        The user agent allows origin servers to run a custom algorithm
        which guesses the best variant for the request, and to return
        this variant in a choice response, if the resulting choice
        response is smaller than or not much larger than a list
        response.  The definition of `not much larger' is left to
        origin server heuristics.  Implies "vlist" and "trans".

      rvsa-version
        The user agent allows origin servers and proxies to run the
        remote variant selection algorithm with the indicated version
        number, or with the same major version number and a higher
        minor version number.  If the algorithm has sufficient
        information to choose a best, neighboring variant, the origin
        server or proxy MAY return a choice response with this
        variant.  Implies "trans".

      "*"
        The user agent allows origin servers and proxies to run any
        remote variant selection algorithm.  The origin server may
        even run algorithms which have not been standardized.  If the
        algorithm has sufficient information to choose a best,
        neighboring variant, the origin server or proxy MAY return a
        choice response with this variant.  Implies "trans".




Holtman & Mutz                Experimental                     [Page 29]

RFC 2295            Transparent Content Negotiation           March 1998


   Servers SHOULD ignore all negotiate-directives they do not
   understand.  If the Negotiate header allows a choice between multiple
   remote variant selection algorithms which are all supported by the
   server, the server SHOULD use some internal precedence heuristics to
   select the best algorithm.

8.5 TCN

   The TCN response header is used by a server to signal that the
   resource is transparently negotiated.

       TCN = "TCN" ":" #( response-type
                        | server-side-override-directive
                        | tcn-extension )

       response-type = "list" | "choice" | "adhoc"

       server-side-override-directive = "re-choose" | "keep"

       tcn-extension = token [ "=" ( token | quoted-string ) ]

   If the resource is not transparently negotiated, a TCN header MUST
   NOT be included in any response.  If the resource is transparently
   negotiated, a TCN header, which includes the response-type value of
   the response, MUST be included in every response with a 2xx status
   code or any 3xx status code, except 304, in which it MAY be included.
   A TCN header MAY also be included, without a response-type value, in
   other responses from transparently negotiated resources.

   A server-side override directive MUST be included if the origin
   server performed a server-side override when choosing the response.
   If the directive is "re-choose", the server MUST include an
   Alternates header with the variant bound to the negotiable resource
   in the response, and user agent SHOULD use its internal variant
   selection algorithm to choose, retrieve, and display the best variant
   from this list.  If the directive is "keep" the user agent SHOULD NOT
   renegotiate on the res