RE: Interop issue: how can clients force authentication?

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

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.

3) Finally -- we should be looking for *existing* ways to solve this problem
for RFC2518bis. For instance:

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.

3b) Try a zero-length PUT first.

3c) Try a LOCK first.

3d) Try a PUT with known-to-fail If header first (-> Stefan's proposal).

...and so on.


Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Ilya Kirnos
> Sent: Tuesday, September 17, 2002 9:18 PM
> To: Roy T. Fielding
> Cc: Webdav WG
> Subject: Re: Interop issue: how can clients force authentication?
>
>
>
>
> "Roy T. Fielding" wrote:
>
> > Authorization is granted/denied based on the method of the request.
> > There might even be different challenges per method.  In other words,
> > this idea won't work for HTTP.
> >
>
> right, i was hoping to finesse the issue by saying that if any
> method needed
> authentication, the server should challenge.  however, if
> challenges differ
> for different methods, then obviously this won't work.
>
> >
> > The original idea of OPTIONS was that, if the client wished to test the
> > options for a specific request, then it would include that request's
> > request-line and headers in the body of the OPTIONS request.  The server
> > would then look at the body to determine what the options would be and
> > report that back to the client.  However, since the WG did not want to
> > define the format of such a response, the feature got dropped.
> >
> > The alternative was to simply issue the request with Expect:
> 100-continue.
> >
> > I don't know if that is sufficient for your problem, but I do know that
> > using a T/F request header field on OPTIONS is not.  A minimum would be
> > to list the methods in that field instead.  I also suggest finding a
> > less verbose field name.
> >
>
> sounds like an idea to me, but if in fact it is common for servers to have
> different challenges for different methods, then we have a whole
> new set of
> problems.  would the order of the list of methods determine which
> challenge is
> returned?  do clients have to issue this OPTIONS request for each new
> operation they try to do (i.e., i sent a list that had PUT first
> for my last
> operation, but now i'm about to do a PROPPATCH -- do i have to
> send a new list
> that has PROPPATCH first?).
>
> perhaps in its response the server could return which methods the
> challenge
> would cover if successfully answered.  so the sequence would look like:
>
> request:
>
> OPTIONS /blah HTTP/1.1
> Host: blah
> Force-Authenticate: PUT, PROPPATCH, etc...
>
> response:
>
> HTTP/1.1 401 Unauthorized
> WWW-Authenticate: ....
> Authenticate-Methods: PUT, PROPPATCH, etc...
>
> and now the client can send a PUT, PROPPATCH, or etc... if it has
> the right
> credential for the challenge.
>
> From my experience with HTTP server configurations, most
> challenges tend to
> cover either all write methods or none (at least if the
> configuration is done
> properly), but this would leave the door open for those that do something
> different.
>
> -ilya
>
>

Received on Tuesday, 17 September 2002 16:27:42 UTC