- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 18 Sep 2002 01:38:06 +0200
- To: "Ilya Kirnos" <ilya.kirnos@oracle.com>, "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
> 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. So please restate what was considered to be an actual interop problem. > > > > 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. > > > > 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). > > 3) Finally -- we should be looking for *existing* ways to solve > this problem > > for RFC2518bis. For instance: > > > > we also discussed this in the meeting and rejected in turn each > method that came > up. none of them seemed reliable/clean enough, but i'm willing to hear > suggestions. (see my comments below) > > > > > > 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. > > > > likely, but not certain. and now you've possibly changed the metadata. > > > > > 3b) Try a zero-length PUT first. > > > > probably would work, but leaves a file behind (remember, i just wanted to > authenticate, not necessarily upload anything.) Right. Lesson learned -- it doesn't make sense to try to come up for workarounds until the problem is clearly stated. > > 3c) Try a LOCK first. > > > > servers don't have to support locking. Yes. Servers don't have to support authentication either. > > 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, ... -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 17 September 2002 19:38:13 UTC