Re: Allow header after Authentication

Hello,

currently Allow can be used to determine for which verbs it is hopeless
to try to execute, because the caller can be sure, that if allow does
not list a method, the method is not available.

Specifications follow an aim, the purpose of the Allow header is
strictly to inform the recipient of valid request methods associated
with the resource.

This information cannot be used to save round-trips determining whether
a user can call a valid method, if all clients/users get the same Allow
response.

What can a client do with the returned information?

I mean, if the majority view is that authentication plays no role when
the header is generated, because the text doesn't mandate the opposite,
and the clients applications' of the returned data are not very useful,
then the rfc-text can be changed to contain authentication.

Greetings
  Дилян

On Tue, 2018-06-26 at 11:29 -0700, Roy T. Fielding wrote:
> > On Jun 25, 2018, at 4:53 PM, Дилян Палаузов <dilyan.palauzov@aegee.
> > org> wrote:
> > 
> > Hello,
> > 
> > how is Allow: different from WebDAV ACL "DAV:current-user-
> > privilege-
> > set" [
> > https://tools.ietf.org/html/rfc3744#section-5.4 ]: "DAV:current-
> > user-
> > privilege-set is a protected property containing the exact set of
> > privileges (as computed by the server) granted to the currently
> > authenticated HTTP user."?
> 
> They have completely different definitions for different purposes.
> 
> > The WebDav privileges can also change depending on the time of the
> > day,
> > or have different effective permissions being called from laptop or
> > watch, or use other means to authenticate, after the PROPFIND for
> > the
> > resoure was called.
> > 
> > Why does it make sense to return DAV:unbind depending on the
> > authentication, but not Allow: DELETE under the same conditions?
> 
> Because, regardless of its name, Allow has nothing to do with
> authentication
> unless a given resource chooses to make it so.
> 
> To be clear, we are talking about historical artifacts that have a
> specific,
> defined meaning.  Whether or not those meanings are consistent among
> two
> entirely different features of entirely different specifications is
> not even
> remotely open to debate at this point.  Nor is it a question of
> logic, sense,
> or even what might be more useful.  These are already-defined terms
> in
> an already-deployed language.
> 
> ....Roy
> 
>

Received on Tuesday, 3 July 2018 23:01:23 UTC