The meanings of the values of the parameters 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".  The realm is a
     "quoted-string" as specified in section 2.2 of the HTTP/1.1
     specification [2].

     domain
     A comma-separated list of URIs, as specified for HTTP/1.0.  The
     intent is that the client could use this information to know the
     set of URIs for which the same authentication information should be
     sent.  The URIs in this list may exist on different servers.  If
     this keyword is omitted or empty, the client should assume that the
     domain consists of all URIs on the responding server.







 
RFC 2069              Digest Access Authentication          January 1997


     nonce
     A server-specified data string which may 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
     recommended nonce would include

             H(client-IP ":" time-stamp ":" private-key )

     Where client-IP is the dotted quad IP address of the client making
     the request, time-stamp is a server-generated time value,  private-
     key is data known only to the server.  With a nonce of this form a
     server would normally recalculate the nonce after receiving the
     client authentication header and reject the request if it did not
     match the nonce from that header. In this way the server can limit
     the reuse of a nonce to the IP address to which it was issued and
     limit the time of the nonce's validity.  Further discussion of the
     rationale for nonce construction is in section 3.2 below.

     An implementation might choose not to accept a previously used
     nonce or a previously used digest 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 3.
     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.  It is recommended that this
     string be base64 or hexadecimal data.  This field is a
     "quoted-string" as specified in section 2.2 of the HTTP/1.1
     specification [2].

     stale
     A flag, indicating that the previous request from the client was
     rejected because the nonce value was stale.  If stale is TRUE (in
     upper or lower case), the client may wish to simply retry the
     request with a new encrypted response, without reprompting the
     user for a new username and password.  The server should only set
     stale to true if it receives a request for which the nonce is
     invalid but with a valid digest for that nonce (indicating that
     the client knows the correct username/password).




 
RFC 2069              Digest Access Authentication          January 1997


     algorithm
     A string indicating a pair of algorithms used to produce the
     digest and a checksum.  If this not present it is assumed to be
     "MD5". In this document the string obtained by applying the
     digest algorithm to the data "data" with secret "secret" will be
     denoted by KD(secret, data), and the string obtained by applying
     the checksum algorithm to the data "data" will be denoted
     H(data).

     For the "MD5" algorithm

        H(data) = MD5(data)

     and