where "digest-uri-value" is the value of the "uri" directive on the
   Authorization header in the request. The "cnonce-value" and "nc-
   value" MUST be the ones for the client request to which this message
   is the response. The "response-auth", "cnonce", and "nonce-count"
   directives MUST BE present if "qop=auth" or "qop=auth-int" is
   specified.

   The Authentication-Info header is allowed in the trailer of an HTTP
   message transferred via chunked transfer-coding.

3.3 Digest Operation

   Upon receiving the Authorization header, the server may check its
   validity by looking up the password that corresponds to the submitted
   username. Then, the server must perform the same digest operation
   (e.g., MD5) performed by the client, and compare the result to the
   given request-digest value.

   Note that the HTTP server does not actually need to know the user's
   cleartext password. As long as H(A1) is available to the server, the
   validity of an Authorization header may be verified.

   The client response to a WWW-Authenticate challenge for a protection
   space starts an authentication session with that protection space.
   The authentication session lasts until the client receives another
   WWW-Authenticate challenge from any server in the protection space. A
   client should remember the username, password, nonce, nonce count and
   opaque values associated with an authentication session to use to
   construct the Authorization header in future requests within that
   protection space. The Authorization header may be included
   preemptively; doing so improves server efficiency and avoids extra
   round trips for authentication challenges. The server may choose to
   accept the old Authorization header information, even though the
   nonce value included might not be fresh. Alternatively, the server
   may return a 401 response with a new nonce value, causing the client
   to retry the request; by specifying stale=TRUE with this response,
   the server tells the client to retry with the new nonce, but without
   prompting for a new username and password.

   Because the client is required to return the value of the opaque
   directive given to it by the server for the duration of a session,
   the opaque data may be used to transport authentication session state
   information. (Note that any such use can also be accomplished more
   easily and safely by including the state in the nonce.) For example,
   a server could be responsible for authenticating content that
   actually sits on another server. It would achieve this by having the
   first 401 response include a domain directive whose value includes a
   URI on the second server, and an opaque directive whose value




 
RFC 2617                  HTTP Authentication                  June 1999


   contains the state information. The client will retry the request, at
   which time the server might respond with a 301/302 redirection,
   pointing to the URI on the second server. The client will follow the
   redirection, and pass an Authorization header , including the
    data.

   As with the basic scheme, proxies must be completely transparent in
   the Digest access authentication scheme. That is, they must forward
   the WWW-Authenticate, Authentication-Info and Authorization headers
   untouched. If a proxy wants to authenticate a client before a request
   is forwarded to the server, it can be done using the Proxy-
   Authenticate and Proxy-Authorization headers described in section 3.6
   below.

3.4 Security Protocol Negotiation

   It is useful for a server to be able to know which security schemes a
   client is capable of handling.

   It is possible that a server may want to require Digest as its
   authentication method, even if the server does not know that the
   client supports it. A client is encouraged to fail gracefully if the
   server specifies only authentication schemes it cannot handle.

3.5 Example

   The following example assumes that an access-protected document is
   being requested from the server via a GET request. The URI of the
   document is "http://www.nowhere.org/dir/index.html". Both client and
   server know that the username for this document is "Mufasa", and the
   password is "Circle Of Life" (with one space between each of the
   three words).

   The first time the client requests the document, no Authorization
   header is sent, so the server responds with:

         HTTP/1.1 401 Unauthorized
         WWW-Authenticate: Digest
                 realm="testrealm@host.com",
                 qop="auth,auth-int",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41"