Subject: Re: Allow header after Authentication

From: Дилян Палаузов <[email-masked]>
Date: Tue, 03 Jul 2018 23:00:51 +0000

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

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 4 Jul 2018 18:19:46 +1200

> What can a client do with the returned information?

Some clients do have a use for it. Which is why it exists. That use may
or many not have anything to do with any use-case you know of.

In the middleware world we use Allow to auto-negotiate what subsets of
HTTP and HTTP-like protocols are able to work on a particular port /
connection:
 Clients send a probe request and the Allow header produced hints at
whether the messages the client needs to perform will work through that
proxy. RTSP, SIP, ICAP, ICY, and WebDAV are all common possibilities
which some clients probe for in this way. These probe results are
assumed to remain for the duration of the connection lifetime, whereas
authentication may change per-message.

> then the rfc-text can be changed to contain authentication.

Majority is not enough. Near-unanimity, or at least proof of the change
not breaking any currently existing software is necessary. The client
examples I mention above are for non-HTTP protocols whose software will
absolutely break in unexpected ways if HTTP changes here.

As Roy said, the spec was written and deployed over 30 years ago. So
there is a HUGE amount of deployed software that may be relying on its
current behaviour.

Amos