Re: Interop issue: how can clients force authentication?

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