W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

Re: Interop issue: how can clients force authentication?

From: Ilya Kirnos <ilya.kirnos@oracle.com>
Date: Tue, 17 Sep 2002 18:38:56 -0700
Message-ID: <3D87D930.66156D05@oracle.com>
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.

Received on Tuesday, 17 September 2002 21:37:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:01 GMT