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

Re: Allow header after Authentication

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Tue, 26 Jun 2018 12:57:18 +1200
To: ietf-http-wg@w3.org
Message-ID: <d389fc78-aa11-94d8-62a2-975f1247c8d1@treenet.co.nz>
On 26/06/18 11:53, Дилян Палаузов 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."?
> 


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


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

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


> Why does it make sense to return DAV:unbind depending on the
> 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
Received on Tuesday, 26 June 2018 00:57:51 UTC

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