- From: Paul Leach <paulle@microsoft.com>
- Date: Wed, 28 Feb 96 21:14:50 PST
- To: john@math.nwu.edu
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
] ] > So, how about the following parameter for both Authorization and ] > WWW-Authenticate headers: ] > digest-required=<"message" | "header" | "response"> ] > where "message" means the receiver must include ] > message=<message-digest> ] > in the response, "header" means the receiver must include ] > header=<header-digest> ] > in the response, and "response" means the receiver must include ] > response=<response-digest> ] > in the response. ] > ] ] I don't like this. How can you require an optional header. The client ] has to take it or leave it. The alternative is something much different ] from a drop in replacement for Basic. If the client asks for it and the ] server can't provide it, then what? This opens a whole new set of ] issues. Sorry. All the "requires" and "musts" are my fascist upbringing peeking through depsite my best attempts to keep it under control. It would better reflect proper HTTP etiquette if I had said: So, how about the following parameter for both Authorization and WWW-Authenticate headers: digest-requested=<"message" | "header" | "response"> where "message" means the receiver is asked to include message=<message-digest> in the response, "header" means the receiver is asked to include header=<header-digest> in the response, and "response" means the receiver is asked to include response=<response-digest> in the response. I.e, the sender is requesting the receiver to include an optional header if it wants. If the receiver doesn't, what the sender does is up to it. The server could just say that the client doesn't get the requested resource, fo example. In this respect, it's not much different than WWW-Authenticate being an optional header -- the client doesn't have to repond with an Authorization header, but if it doesn't, it usually doesn't get the resource it wants. Is that better? Paul
Received on Wednesday, 28 February 1996 21:10:30 UTC