- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 17 Sep 2002 21:46:52 +0200
- To: "Ilya Kirnos" <ilya.kirnos@oracle.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
Some thoughts.... 1) Do we really have an interop issue at all? From what I hear, it's considered a problem that when submitting a large PUT, you may not hear about the 401 before you have sent the whole request. So that's "just" a performance issue (actually, a known one). 2) If there *would be* consensus that we need this kind of you-wikll-have-to-authenticate-for-PUT signalling, I'd propose to make this a live property. Just issue a PROPFIND on it in case you want to know. No new request header (-> HTTP header namespace unaffected), no new OPTIONS semantics, no new compliance class. 3) Finally -- we should be looking for *existing* ways to solve this problem for RFC2518bis. For instance: 3a) Try a PROPPATCH first -- if you can't change the metadata, it's likely that you won't be able to change the content either. 3b) Try a zero-length PUT first. 3c) Try a LOCK first. 3d) Try a PUT with known-to-fail If header first (-> Stefan's proposal). ...and so on. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Ilya Kirnos > Sent: Tuesday, September 17, 2002 9:18 PM > To: Roy T. Fielding > Cc: Webdav WG > Subject: Re: Interop issue: how can clients force authentication? > > > > > "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 16:27:42 UTC