- From: Ilya Kirnos <ilya.kirnos@oracle.com>
- Date: Tue, 17 Sep 2002 15:24:29 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: Webdav WG <w3c-dist-auth@w3c.org>
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. > > 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. > > 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.) > > 3c) Try a LOCK first. > servers don't have to support locking. > > 3d) Try a PUT with known-to-fail If header first (-> Stefan's proposal). > maybe. what's known to fail? -ilya
Received on Tuesday, 17 September 2002 18:22:46 UTC