Re: Allow header after Authentication

On 04/07/18 11:00, Дилян Палаузов wrote:
> 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?

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.


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

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

Received on Wednesday, 4 July 2018 06:20:19 UTC