Subject: Allow header after Authentication

From: Дилян Палаузов <[email-masked]>
Date: Mon, 25 Jun 2018 21:29:25 +0000

Hello,

https://tools.ietf.org/html/rfc7231#section-7.4.1 "Allow header" says:
[

The "Allow" header field lists the set of methods advertised as
supported by the target resource. The purpose of this field is strictly
to inform the recipient of valid request methods associated with the
resource.

] Because the text above does not say anything about authorizaion, one
possible implementation of Allow is to return the same method list to
all - authenticated and not authenticated - clients.

What would be the use of a returned
  Allow: GET, HEAD, DELETE
to a client, if the client is authenticated at the time the request is
made and the server knows that with the provided
authentication/authorization the client cannot perform DELETE?

Regards
  Дилян

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 25 Jun 2018 15:44:17 -0700

> On Jun 25, 2018, at 2:29 PM, Дилян Палаузов <[email-masked]> wrote:
> 
> Hello,
> 

It says nothing about it because that is a choice for the resource in question.

> authentication/authorization the client cannot perform DELETE?

Because they might do their DELETE using a different set of credentials than
in the initial GET.  Or maybe the authorization is based on time-of-day instead
of fixed roles.  Or maybe the DELETE only works when initiated by their watch
instead of their laptop.  Or maybe the server just doesn't care that an unauthorized
DELETE will encounter a 401 response.  Or maybe it's a honey trap.

The Allow field doesn't talk about access control or authorization because
they are not part of its definition. However, a server can choose to advertise
whatever method it wants, for whatever reason it chooses to do so.

....Roy

---

From: Дилян Палаузов <[email-masked]>
Date: Mon, 25 Jun 2018 23:53:45 +0000

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."?

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?

Regards
  Дилян

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 26 Jun 2018 12:57:18 +1200

> authenticated HTTP user."?

Note the words "exact set of privileges" and "currently authenticated".
Particularly how they are used in that definition but absent in the HTTP
specification texts about Allow.

Also, HTTP methods != WebDAV privileges.

That is two very obvious differences. There may be others. Perhapse you
should read the mechanism definitions and compare them yourself instead
of asking us to explain everything?
(Sorry if that sounds grumpy and blunt, but this is not exactly a
generic help forum for beginners).

> watch, or use other means to authenticate, after the PROPFIND for the

Think about that in terms of the above differences I pointed out.

> authentication, but not Allow: DELETE under the same conditions?

Different protocols do different things, have different limits,
different use-cases, and different objectives. Even when there is
overlap those differences are in effect. So why do you expect them to
repeat the same criteria?

In fact the opposite is true; a spec like WebDAV layered on top of HTTP
should define things when there are differences and reference the base
HTTP spec when things are the same.

AYJ

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 26 Jun 2018 11:29:27 -0700

> On Jun 25, 2018, at 4:53 PM, Дилян Палаузов <[email-masked]> wrote:
> 
> Hello,
> 

They have completely different definitions for different purposes.

> 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