PROXY  WHOIS  RQUOTE  TEXTS  SOFT  FOREX  BBOARD
 Music  Philosophy  Code  Literature  Russian

= ROOT|Technical|Proxy_Docs|rfc2296.txt =

page 2 of 8




3.1 Input

     The algorithm is always run for a particular request on a
     particular transparently negotiable resource.  It takes the
     following information as input.

    1. The variant list of the resource, as present in the Alternates
       header of the resource.




 
RFC 2296                     HTTP RVSA/1.0                    March 1998


    2. (Partial) Information about capabilities and preferences of the
       user agent for this particular request, as given in the Accept-
       headers of the request.

   If a fallback variant description

       {"fallback.html"}

   is present in the Alternates header, the algorithm MUST interpret it
   as the variant description

       {"fallback.html" 0.000001}

   The extremely low source quality value ensures that the fallback
   variant only gets chosen if all other options are exhausted.

3.2 Output

   As its output, the remote variant selection algorithm and will yield
   the appropriate action to be performed.  There are two possibilities:

      Choice_response

        The Accept- headers contain sufficient information to make a
        choice on behalf of the user agent possible, and the best
        variant MAY be returned in a choice response.

      List_response

        The Accept- headers do not contain sufficient information to
        make a choice on behalf of the user agent possible.  A list
        response MUST be returned, allowing the user agent to make the
        choice itself.

3.3 Computing overall quality values

   As a first step in the remote variant selection algorithm, the
   overall qualities of the individual variants in the list are
   computed.

   The overall quality Q of a variant is the value

      Q = round5( qs * qt * qc * ql * qf )

   where round5 is a function which rounds a floating point value to 5
   decimal places after the point, and where the factors qs, qt, qc, ql,
   and qf are determined as follows.





 
RFC 2296                     HTTP RVSA/1.0                    March 1998


      qs Is the source quality factor in the variant description.

      qt The media type quality factor is 1 if there is no type
         attribute in the variant description, or if there is no Accept
         header in the request.  Otherwise, it is the quality assigned
         by the Accept header to the media type in the type attribute.

           Note: If a type is matched by none of the elements of an
           Accept header, the Accept header assigns the quality factor 0
           to that type.

      qc The charset quality factor is 1 if there is no charset
         attribute in the variant description, or if there is no
         Accept-Charset header in the request.  Otherwise, the charset
         quality factor is the quality assigned by the Accept-Charset
         header to the charset in the charset attribute.

      ql The language quality factor is 1 if there is no language
         attribute in the variant description, or if there is no
         Accept-Language header in the request.  Otherwise, the language
         quality factor is the highest quality factor assigned by the
         Accept-Language header to any one of the languages listed in
         the language attribute.

      qf The features quality factor is 1 if there is no features
         attribute in the variant description, or if there is no
         Accept-Features header in the request.  Otherwise, it is the
=2=

1| < PREV = PAGE 2 = NEXT > |3|4|5|6|7|8

UP TO ROOT | UP TO DIR | TO FIRST PAGE

Google
 


E-mail Facebook Google Digg del.icio.us BlinkList Fark Furl Ma.gnolia Netscape NewsVine Reddit Slashdot Spurl StumbleUpon Technorati YahooMyWeb LiveJournal Blogmarks TwitThis Live News2.ru BobrDobr.ru Memori.ru MoeMesto.ru

0.028455 wallclock secs ( 0.01 usr + 0.00 sys = 0.01 CPU)