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.

>
> 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