W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

RE: i24: Requiring Allow in 405 responses

From: Brian Smith <brian@briansmith.org>
Date: Fri, 29 Feb 2008 10:21:48 -0800
To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <005a01c87aff$f37c2df0$6401a8c0@T60>

Stefan Eissing wrote:
> Am 29.02.2008 um 00:25 schrieb Mark Nottingham:
> > On 28/02/2008, at 11:26 PM, Julian Reschke wrote:
> >
> >> It seems to me it would be unwise to say "clients SHOULD 
> >> believe the Allow header", but "servers MAY leave of methods".
> >>
> >> If we relax the requirement for the production, we also 
> >> need to relax the requirement for the recipient.
> >
> >
> > How about
> >
> > Clients SHOULD believe the Allow header
> > Servers SHOULD send a complete Allow header
> "SHOULD believe" is a new one to me.
> How about describing the Server requirements and leaving it at that?  

The Allow header does not give enough information to be usefully
processed by a client. The absence of a method in an Allow header does
not mean that the method should not be used. It just means that the
server explicitly supported that method *at the time the response was
generated*, and it is unlikely to support the methods until some
*unspecified* server state changes.

How long should the client cache the value of an Allow header?
Currently, that is up to the client. Is a client *required* to cache the
Allow header from a previous response so that it can make use of it in a
future response? No. Should a client avoid methods that aren't listed in
a cached Allow header? No, because that requires the client to cache
previous Allow headers (plus, how did it get the Allow header that tells
it what is allowed, without making a request?).

This mechanism would little more sensible if there was a Disallow header
that specifically listed methods that the server intends to always
reject until some (unspecified) server state changes. Then you could say
that the client SHOULD NOT use a method listed in Disallow unless or
until it thinks the information in the header is invalid (stale).
"Disallow: *" would mean that *only* the methods listed in the Allow
header were valid at the time the response was generated, and only those
methods will be supported until some (unspecified) server state changes.
If the method is not explicitly allowed or disallowed, then the validity
of the method is considered to be unspecified. 

- Brian
Received on Friday, 29 February 2008 18:21:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC