[2], but it MUST agree with the Request-URI. In particular, it MUST
   be an "absoluteURL" if the Request-URI is an "absoluteURL". The
   "cnonce-value" is an optional  client-chosen value whose purpose is
   to foil chosen plaintext attacks.

   The authenticating server must assure that the resource designated by
   the "uri" directive is the same as the resource specified in the
   Request-Line; if they are not, the server SHOULD return a 400 Bad
   Request error. (Since this may be a symptom of an attack, server
   implementers may want to consider logging such errors.) The purpose
   of duplicating information from the request URL in this field is to
   deal with the possibility that an intermediate proxy may alter the
   client's Request-Line. This altered (but presumably semantically
   equivalent) request would not result in the same digest as that
   calculated by the client.

   Implementers should be aware of how authenticated transactions
   interact with shared caches. The HTTP/1.1 protocol specifies that
   when a shared cache (see section 13.7 of [2]) has received a request
   containing an Authorization header and a response from relaying that
   request, it MUST NOT return that response as a reply to any other
   request, unless one of two Cache-Control (see section 14.9 of [2])
   directives was present in the response. If the original response
   included the "must-revalidate" Cache-Control directive, the cache MAY
   use the entity of that response in replying to a subsequent request,
   but MUST first revalidate it with the origin server, using the
   request headers from the new request to allow the origin server to
   authenticate the new request. Alternatively, if the original response
   included the "public" Cache-Control directive, the response entity
   MAY be returned in reply to any subsequent request.

3.2.3 The Authentication-Info Header

   The Authentication-Info header is used by the server to communicate
   some information regarding the successful authentication in the
   response.






 
RFC 2617                  HTTP Authentication                  June 1999


        AuthenticationInfo = "Authentication-Info" ":" auth-info
        auth-info          = 1#(nextnonce | [ message-qop ]
                               | [ response-auth ] | [ cnonce ]
                               | [nonce-count] )
        nextnonce          = "nextnonce" "=" nonce-value
        response-auth      = "rspauth" "=" response-digest
        response-digest    = <"> *LHEX <">

   The value of the nextnonce directive is the nonce the server wishes
   the client to use for a future authentication response.  The server
   may send the Authentication-Info header with a nextnonce field as a
   means of implementing one-time or otherwise changing  nonces. If the
   nextnonce field is present the client SHOULD use it when constructing
   the Authorization header for its next request. Failure of the client
   to do so may result in a request to re-authenticate from the server
   with the "stale=TRUE".

     Server implementations should carefully consider the performance
     implications of the use of this mechanism; pipelined requests will
     not be possible if every response includes a nextnonce directive
     that must be used on the next request received by the server.
     Consideration should be given to the performance vs. security
     tradeoffs of allowing an old nonce value to be used for a limited
     time to permit request pipelining.  Use of the nonce-count can
     retain most of the security advantages of a new server nonce
     without the deleterious affects on pipelining.

   message-qop
     Indicates the "quality of protection" options applied to the
     response by the server.  The value "auth" indicates authentication;
     the value "auth-int" indicates authentication with integrity
     protection. The server SHOULD use the same value for the message-
     qop directive in the response as was sent by the client in the
     corresponding request.

   The optional response digest in the "response-auth" directive
   supports mutual authentication -- the server proves that it knows the
   user's secret, and with qop=auth-int also provides limited integrity
   protection of the response. The "response-digest" value is calculated
   as for the "request-digest" in the Authorization header, except that
   if "qop=auth" or is not specified in the Authorization header for the
   request, A2 is

      A2       = ":" digest-uri-value

   and if "qop=auth-int", then A2 is

      A2       = ":" digest-uri-value ":" H(entity-body)




 
RFC 2617                  HTTP Authentication                  June 1999