W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: Allow header after Authentication

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 25 Jun 2018 15:44:17 -0700
Cc: ietf-http-wg@w3.org
Message-Id: <C1A748CF-0182-4571-A524-D184B5B33172@gbiv.com>
To: Дилян Палаузов <dilyan.palauzov@aegee.org>
> On Jun 25, 2018, at 2:29 PM, Дилян Палаузов <dilyan.palauzov@aegee.org> wrote:
> 
> 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.

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

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

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
Received on Monday, 25 June 2018 22:44:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:21 UTC