- From: Ilya Kirnos <ilya.kirnos@oracle.com>
- Date: Tue, 17 Sep 2002 12:17:34 -0700
- To: "Roy T. Fielding" <fielding@apache.org>
- CC: Webdav WG <w3c-dist-auth@w3c.org>
"Roy T. Fielding" wrote: > Authorization is granted/denied based on the method of the request. > There might even be different challenges per method. In other words, > this idea won't work for HTTP. > right, i was hoping to finesse the issue by saying that if any method needed authentication, the server should challenge. however, if challenges differ for different methods, then obviously this won't work. > > The original idea of OPTIONS was that, if the client wished to test the > options for a specific request, then it would include that request's > request-line and headers in the body of the OPTIONS request. The server > would then look at the body to determine what the options would be and > report that back to the client. However, since the WG did not want to > define the format of such a response, the feature got dropped. > > The alternative was to simply issue the request with Expect: 100-continue. > > I don't know if that is sufficient for your problem, but I do know that > using a T/F request header field on OPTIONS is not. A minimum would be > to list the methods in that field instead. I also suggest finding a > less verbose field name. > sounds like an idea to me, but if in fact it is common for servers to have different challenges for different methods, then we have a whole new set of problems. would the order of the list of methods determine which challenge is returned? do clients have to issue this OPTIONS request for each new operation they try to do (i.e., i sent a list that had PUT first for my last operation, but now i'm about to do a PROPPATCH -- do i have to send a new list that has PROPPATCH first?). perhaps in its response the server could return which methods the challenge would cover if successfully answered. so the sequence would look like: request: OPTIONS /blah HTTP/1.1 Host: blah Force-Authenticate: PUT, PROPPATCH, etc... response: HTTP/1.1 401 Unauthorized WWW-Authenticate: .... Authenticate-Methods: PUT, PROPPATCH, etc... and now the client can send a PUT, PROPPATCH, or etc... if it has the right credential for the challenge. From my experience with HTTP server configurations, most challenges tend to cover either all write methods or none (at least if the configuration is done properly), but this would leave the door open for those that do something different. -ilya
Received on Tuesday, 17 September 2002 15:15:52 UTC