capabilities, to get optimal results.  For example, instead of
   sending

     Accept: image/gif;q=0.9, image/jpeg;q=0.8, image/png;q=1.0,
             image/tiff;q=0.5, image/ief;q=0.5, image/x-xbitmap;q=0.8,
             application/plugin1;q=1.0, application/plugin2;q=0.9

   the user agent can send

     Accept: image/gif;q=0.9, */*;q=1.0

   It can send this short header without running the risk of getting a
   choice response with, say, an inferior image/tiff variant.  For
   example, with the variant list

     {"x.gif" 1.0 {type image/gif}}, {"x.tiff" 1.0 {type image/tiff}},

   the remote algorithm will compute a definite overall quality of 0.9
   for x.gif and a speculative overall quality value of 1.0 for x.tiff.
   As the best variant has a speculative quality value, the algorithm
   will not choose x.tiff, but return a list response, after which the
   selection algorithm of the user agent will correctly choose x.gif.
   The end result is the same as if the long Accept- header above had
   been sent.

   Thus, user agents can vary the length of the Accept- headers to get
   an optimal tradeoff between the speed with which the first request is
   transmitted, and the chance that the remote algorithm has enough
   information to eliminate a second request.

4.2.1 Collapsing Accept- header elements

   This section discusses how a long Accept- header which lists all
   capabilities and preferences can be safely made shorter.  The remote
   variant selection algorithm is designed in such a way that it is
   always safe to shorten an Accept or Accept-Charset header by two
   taking two header elements `A;q=f' and `B;q=g' and replacing them by
   a single element `P;q=m' where P is a wildcard pattern that matches
   both A and B, and m is the maximum of f and g.  Some examples are

      text/html;q=1.0, text/plain;q=0.8       -->    text/*;q=1.0
      image/*;q=0.8, application/*;q=0.7      -->    */*;q=0.8

      iso-8859-5;q=1.0, unicode-1-1;q=0.8     -->    *;q=1.0




 
RFC 2296                     HTTP RVSA/1.0                    March 1998


   Note that every `;q=1.0' above is optional, and can be omitted:

      iso-8859-7;q=0.6, *                     -->    *

   For Accept-Language, it is safe to collapse all language ranges
   with the same primary tag into a wildcard:

      en-us;q=0.9, en-gb;q=0.7, en;q=0.8, da  -->    *;q=0.9, da

   It is also safe to collapse a language range into a wildcard, or to
   replace it by a wildcard, if its primary tag appears only once:

      *;q=0.9, da                             -->    *

   Finally, in the Accept-Features header, every feature expression
   can be collapsed into a wildcard, or replaced by a wildcard:

      colordepth!=5, *                        -->    *

4.2.2 Omitting Accept- headers

   According to the HTTP/1.1 specification [1], the complete absence of
   an Accept header from the request is equivalent to the presence of
   `Accept: */*'.  Thus, if the Accept header is collapsed to `Accept:
   */*', a user agent may omit it entirely.  An Accept-Charset, Accept-
   Language, or Accept-Features header which only contains `*' may also
   be omitted.

4.2.3 Dynamically lengthening requests

   In general, a user agent capable of transparent content negotiation
   can send short requests by default.  Some short Accept- headers could
   be included for the benefit of existing servers which use HTTP/1.0
   style negotiation (see section 4.2 of [2]).  An example is

      GET /paper HTTP/1.1
      Host: x.org
      User-Agent: WuxtaWeb/2.4
      Negotiate: 1.0
      Accept-Language: en, *;q=0.9

   If the Accept- headers included in such a default request are not
   suitable as input to the remote variant selection algorithm, the user
   agent can disable the algorithm by sending `Negotiate: trans' instead
   of `Negotiate: 1.0'.