follows.

entity-digest = <"> KD (H(A1), unquoted nonce-value ":" Method ":"
                           date ":" entity-info ":" H(entity-body)) <">
       ; format is <"> *LHEX <">

date = = rfc1123-date            ; see section 3.3.1 of [2]
entity-info = H(
          digest-uri-value ":"
          media-type ":"         ; Content-type, see section 3.7 of [2]
          *DIGIT ":"             ; Content length, see 10.12 of [2]
          content-coding ":"     ; Content-encoding, see 3.5 of [2]
          last-modified ":"      ; last modified date, see 10.25 of [2]
          expires                ; expiration date; see 10.19 of [2]
          )

last-modified   = rfc1123-date  ; see section 3.3.1 of [2]
expires         = rfc1123-date

   The entity-info elements incorporate the values of the URI used to
   request the entity as well as the associated entity headers Content-
   type, Content-length, Content-encoding, Last-modified, and Expires.
   These headers are all end-to-end headers (see section 13.5.1 of [2])
   which must not be modified by proxy caches.  The "entity-body" is as
   specified by section 10.13 of [2] or RFC 1864.

   Note that not all entities will have an associated URI or all of
   these headers.  For example, an entity which is the data of a POST
   request will typically not have a digest-uri-value or Last-modified
   or Expires headers.  If an entity does not have a digest-uri-value or
   a header corresponding to one of the entity-info fields, then that
   field is left empty in the computation of entity-info.  All the
   colons specified above are present, however.  For example the value
   of the entity-info associated with POST data which has content-type
   "text/plain", no content-encoding and a length of 255 bytes would be
   H(:text/plain:255:::).  Similarly a request may not have a "Date"
   header.  In this case the date field of the entity-digest should be
   empty.

   In the entity-info and entity-digest computations, except for the
   blank after the comma in "rfc1123-date", there must be no white space
   between "words" and "tspecials", and exactly one blank between
   "words" (see section 2.2 of [2]).







 
RFC 2069              Digest Access Authentication          January 1997


   Implementors should be aware of how authenticated transactions
   interact with proxy caches.  The HTTP/1.1 protocol specifies that
   when a shared cache (see section 13.10 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.

2.1.3 The AuthenticationInfo Header

   When authentication succeeds, the Server may optionally provide a
   Authentication-info header indicating that the server wants to
   communicate some information regarding the successful authentication
   (such as an entity digest or a new nonce to be used for the next
   transaction).  It has two fields, digest and nextnonce.  Both are
   optional.

    AuthenticationInfo = "Authentication-info" ":"
                                      1#( digest | nextnonce )

    nextnonce      = "nextnonce" "=" nonce-value

    digest = "digest" "=" entity-digest

   The optional digest allows the client to verify that the body of the
   response has not been changed en-route.  The server would probably
   only send this when it has the document and can compute it.  The
   server would probably not bother generating this header for CGI
   output.  The value of the "digest" is an <entity-digest> which is
   computed as described above.

   The value of the nextnonce parameter is the nonce the server wishes
   the client to use for the next authentication response.  Note that
   either field is optional.  In particular the server may send the
   Authentication-info header with only the nextnonce field as a means
   of implementing one-time nonces.  If the nextnonce field is present
   the client is strongly encouraged to use it for the next WWW-
   Authenticate header.  Failure of the client to do so may result in a
   request to re-authenticate from the server with the "stale=TRUE."