RE: Interop issue: how can clients force authentication?

> 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