W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

Re: HTTP-authentication-01.txt comments

From: Scott Lawrence <lawrence@agranat.com>
Date: Tue, 14 Apr 1998 16:00:04 -0400 (EDT)
To: John Franks <john@math.nwu.edu>
Cc: http-wg@cuckoo.hpl.hp.com, http-wg@hplb.hpl.hp.com
Message-Id: <Pine.LNX.3.96.980414155931.17886A-100000@alice.agranat.com>

> From: John Franks <john@math.nwu.edu>

> Another question: Unless I am mistaken, at one point in the long
> sequence of digest drafts, the Authentication-Info header could be
> supplied by either the server or the client.  It would be useful
> for the client to be able to supply the digest of POSTed data
> or a file which is PUT.  Being able to assure the integrity of
> client supplied data would be very useful.  Did this fall through
> the cracks, or am I just missing this functionality somewhere in
> the draft?

  It is in the Authorization header now.  In section 3.2.2, it says:


]    request-digest  = <"> < KD ( H(A1),     unq(nonce-value)
]                                        ":" nc-value
]                                        ":" unq(cnonce-value)
]                                        ":" unq(qop-value)
]                                        ":" H(A2)
]                                ) <">
   ...
] If the "qop" directive's value is "auth" or is unspecified, then A2 is:
]
]    A2       = Method ":" digest-uri-value
]
] If the "qop" value is "auth-int", then A2 is:
]
]    A2       = Method ":" digest-uri-value ":" H(entity-body)

  So A2 in the response digest (poor name, that, because it is the
  response to the challenge, but it appears in a request) contains the
  hash of the body.  That way we don't need another header.  I don't
  believe that we specified that this may appear in a trailer,
  though.
Received on Tuesday, 14 April 1998 13:03:35 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:14 EDT