- From: Eric Sedlar <eric.sedlar@oracle.com>
- Date: Tue, 17 Sep 2002 17:26:23 -0700
- To: "Julian Reschke" <julian.reschke@gmx.de>, "Ilya Kirnos" <ilya.kirnos@oracle.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
- Cc: "Sam Idicula" <Sam.Idicula@oracle.com>
What we do is to send the authentication challenge for any method other than GET or HEAD or OPTIONS. I recall from the interop event that a number of other servers did the same thing. Most clients issue a LOCK or PROPFIND first and avoid this problem, but perhaps this could be spelled out in the spec. --Eric ----- Original Message ----- From: "Julian Reschke" <julian.reschke@gmx.de> To: "Ilya Kirnos" <ilya.kirnos@oracle.com>; "Webdav WG" <w3c-dist-auth@w3c.org> Sent: Tuesday, September 17, 2002 12:46 PM Subject: RE: Interop issue: how can clients force authentication? > > 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 20:31:53 UTC