If a server receives a request for an access-protected object, and an
   acceptable Authorization header is not sent, the server responds with
   a "401 Unauthorized" status code, and a WWW-Authenticate header as
   per the framework defined above, which for the digest scheme is
   utilized as follows:

      challenge        =  "Digest" digest-challenge

      digest-challenge  = 1#( realm | [ domain ] | nonce |
                          [ opaque ] |[ stale ] | [ algorithm ] |
                          [ qop-options ] | [auth-param] )


      domain            = "domain" "=" <"> URI ( 1*SP URI ) <">
      URI               = absoluteURI | abs_path
      nonce             = "nonce" "=" nonce-value
      nonce-value       = quoted-string
      opaque            = "opaque" "=" quoted-string
      stale             = "stale" "=" ( "true" | "false" )
      algorithm         = "algorithm" "=" ( "MD5" | "MD5-sess" |
                           token )
      qop-options       = "qop" "=" <"> 1#qop-value <">
      qop-value         = "auth" | "auth-int" | token

   The meanings of the values of the directives used above are as
   follows:

   realm
     A string to be displayed to users so they know which username and
     password to use. This string should contain at least the name of
     the host performing the authentication and might additionally
     indicate the collection of users who might have access. An example
     might be "registered_users@gotham.news.com".

   domain
     A quoted, space-separated list of URIs, as specified in RFC XURI
     [7], that define the protection space.  If a URI is an abs_path, it
     is relative to the canonical root URL (see section 1.2 above) of
     the server being accessed. An absoluteURI in this list may refer to
     a different server than the one being accessed. The client can use
     this list to determine the set of URIs for which the same
     authentication information may be sent: any URI that has a URI in
     this list as a prefix (after both have been made absolute) may be
     assumed to be in the same protection space. If this directive is
     omitted or its value is empty, the client should assume that the
     protection space consists of all URIs on the responding server.




 
RFC 2617                  HTTP Authentication                  June 1999


     This directive is not meaningful in Proxy-Authenticate headers, for
     which the protection space is always the entire proxy; if present
     it should be ignored.

   nonce
     A server-specified data string which should be uniquely generated
     each time a 401 response is made. It is recommended that this
     string be base64 or hexadecimal data. Specifically, since the
     string is passed in the header lines as a quoted string, the
     double-quote character is not allowed.

     The contents of the nonce are implementation dependent. The quality
     of the implementation depends on a good choice. A nonce might, for
     example, be constructed as the base 64 encoding of

         time-stamp H(time-stamp ":" ETag ":" private-key)

     where time-stamp is a server-generated time or other non-repeating
     value, ETag is the value of the HTTP ETag header associated with
     the requested entity, and private-key is data known only to the
     server.  With a nonce of this form a server would recalculate the
     hash portion after receiving the client authentication header and
     reject the request if it did not match the nonce from that header
     or if the time-stamp value is not recent enough. In this way the
     server can limit the time of the nonce's validity. The inclusion of
     the ETag prevents a replay request for an updated version of the
     resource.  (Note: including the IP address of the client in the
     nonce would appear to offer the server the ability to limit the
     reuse of the nonce to the same client that originally got it.
     However, that would break proxy farms, where requests from a single
     user often go through different proxies in the farm. Also, IP
     address spoofing is not that hard.)

     An implementation might choose not to accept a previously used
     nonce or a previously used digest, in order to protect against a
     replay attack. Or, an implementation might choose to use one-time
     nonces or digests for POST or PUT requests and a time-stamp for GET
     requests.  For more details on the issues involved see section 4.
     of this document.

     The nonce is opaque to the client.

   opaque
     A string of data, specified by the server, which should be returned
     by the client unchanged in the Authorization header of subsequent
     requests with URIs in the same protection space. It is recommended