- From: Ilya Kirnos <ilya.kirnos@oracle.com>
- Date: Tue, 17 Sep 2002 18:38:56 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: Webdav WG <w3c-dist-auth@w3c.org>
Julian Reschke wrote: > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Ilya Kirnos > > Sent: Wednesday, September 18, 2002 12:24 AM > > To: Julian Reschke > > Cc: Webdav WG > > Subject: Re: Interop issue: how can clients force authentication? > > > > > > > > > > Julian Reschke wrote: > > > > > 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). > > > > > > > that's just one example, although a pretty severe one. in > > general, i believe > > it's a must that clients have a way to authenticate themselves > > when they wish. > > I think at this point you should make clear what problem you want to solve. > > From what I hear now, you want to authenticate, but not for a specific > method call on a specific resource. What is this supposed to *mean*? What > principals are known may depend on the request URI. Whether (and as who) > you need to authenticate to apply a certain method to a resource depends on > the resource *and* the method. > > In general, the answer -- you'lll have to try. > okay. this answer is currently not sufficient, for example in the case of a large PUT. whether it's an interop or a performance problem, i believe it's something that needs to be addressed. if there is something already in the spec that solves the problem, i would be happy to use it. > > So please restate what was considered to be an actual interop problem. > clients need a way to authenticate themselves before performing a potentially expensive operation. the only such operation that has come up in interoperability testing thus far is a large PUT, but it is conceivable that clients will need this for other operations as well. > > we discussed something like this in the WG meeting. an OPTIONS > > header seemed > > like a cleaner approach to me. > > Cleaner in what way? I have listed a few reasons not to use OPTIONS (I even > forgot to mention that it'll save you a roundtrip in case you have to do a > PROPFIND first anyway). > it was largely based on intuition. i guess i'd have to see the exact proposal for this new property to tell you exactly, but if it turns out to be satisfactory, i'd be happy to use it. > > > > 3c) Try a LOCK first. > > > > > > > servers don't have to support locking. > > Yes. Servers don't have to support authentication either. > i don't see your point. these issues are orthogonal: a server may want support authentication but not locking, so i'd like to divorce authentication from locking if at all possible. > > > > 3d) Try a PUT with known-to-fail If header first (-> Stefan's proposal). > > > > > > > maybe. what's known to fail? > > An invalid lock token, an invalid ETag, ... > again, i'd like to stay away from a dependency on locking if possible, and etags support isn't required if i recall correctly. -ilya
Received on Tuesday, 17 September 2002 21:37:13 UTC