Upgrade        = "Upgrade" ":" 1#product

   For example,

          Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

   The Upgrade header field is intended to provide a simple mechanism
   for transition from HTTP/1.1 to some other, incompatible protocol. It
   does so by allowing the client to advertise its desire to use another
   protocol, such as a later version of HTTP with a higher major version
   number, even though the current request has been made using HTTP/1.1.
   This eases the difficult transition between incompatible protocols by
   allowing the client to initiate a request in the more commonly
   supported protocol while indicating to the server that it would like
   to use a "better" protocol if available (where "better" is determined
   by the server, possibly according to the nature of the method and/or
   resource being requested).

   The Upgrade header field only applies to switching application-layer
   protocols upon the existing transport-layer connection. Upgrade
   cannot be used to insist on a protocol change; its acceptance and use
   by the server is optional. The capabilities and nature of the
   application-layer communication after the protocol change is entirely
   dependent upon the new protocol chosen, although the first action
   after changing the protocol MUST be a response to the initial HTTP
   request containing the Upgrade header field.

   The Upgrade header field only applies to the immediate connection.
   Therefore, the upgrade keyword MUST be supplied within a Connection
   header field (section 14.10) whenever Upgrade is present in an
   HTTP/1.1 message.

   The Upgrade header field cannot be used to indicate a switch to a
   protocol on a different connection. For that purpose, it is more
   appropriate to use a 301, 302, 303, or 305 redirection response.

   This specification only defines the protocol name "HTTP" for use by
   the family of Hypertext Transfer Protocols, as defined by the HTTP
   version rules of section 3.1 and future updates to this
   specification. Any token can be used as a protocol name; however, it
   will only be useful if both the client and server associate the name
   with the same protocol.







 
RFC 2068                        HTTP/1.1                    January 1997


14.42 User-Agent

   The User-Agent request-header field contains information about the
   user agent originating the request. This is for statistical purposes,
   the tracing of protocol violations, and automated recognition of user
   agents for the sake of tailoring responses to avoid particular user
   agent limitations. User agents SHOULD include this field with
   requests. The field can contain multiple product tokens (section 3.8)
   and comments identifying the agent and any subproducts which form a
   significant part of the user agent. By convention, the product tokens
   are listed in order of their significance for identifying the
   application.

          User-Agent     = "User-Agent" ":" 1*( product | comment )

   Example:

          User-Agent: CERN-LineMode/2.15 libwww/2.17b3

14.43 Vary

   The Vary response-header field is used by a server to signal that the
   response entity was selected from the available representations of
   the response using server-driven negotiation (section 12). Field-
   names listed in Vary headers are those of request-headers. The Vary
   field value indicates either that the given set of header fields
   encompass the dimensions over which the representation might vary, or
   that the dimensions of variance are unspecified ("*") and thus may
   vary over any aspect of future requests.

          Vary  = "Vary" ":" ( "*" | 1#field-name )

   An HTTP/1.1 server MUST include an appropriate Vary header field with
   any cachable response that is subject to server-driven negotiation.
   Doing so allows a cache to properly interpret future requests on that
   resource and informs the user agent about the presence of negotiation
   on that resource. A server SHOULD include an appropriate Vary header
   field with a non-cachable response that is subject to server-driven
   negotiation, since this might provide the user agent with useful
   information about the dimensions over which the response might vary.

   The set of header fields named by the Vary field value is known as
   the "selecting" request-headers.

   When the cache receives a subsequent request whose Request-URI
   specifies one or more cache entries including a Vary header, the