Re: erratum in RFC 2616: 405 should not require an Allow field in response

On Thu, 2005-06-23 at 16:24 -0700, Roy T. Fielding wrote:
> On Jun 23, 2005, at 4:04 PM, Alex Rousskov wrote:
> >
> > The MUST requirement does not say "a list of ALL valid methods", but
> > perhaps that is implied.
> It is implied by the definition of the Allow header field

Both wordings seem similar to me; neither seems to require that all
methods must be listed. Moreover, the Allow definition says: 

     "The actual set of allowed methods is defined
      by the origin server at the time of each request."

which might imply to some that the list of methods in Allow is dynamic
and not something a client can rely on. FWIW, I believe that
interpretation is close to reality.

> , which
> serves no purpose whatsoever if it does not include all of the
> methods supported by the resource.

The usefulness would depend on the application, I think. I agree that in
some cases it would be useless. On the other hand, any application that
relies on Allow header from an "unknown" server to mean something is
probably not very robust (not to say broken).

> It is better to not send the
> field rather than send an inaccurate field value.

... unless the client knows that the value is just a generally
inaccurate hint.

If we are to fix this, I would suggest two related changes:

	- make Allow optional
	- make it clear that Allow value is imprecise and the
	  reported set of methods may be partial

If you insist that Allow value must be precise, then the wording should
be adjusted to reflect that: We would have to prohibit 501 "Not
Implemented" responses for methods previously listed in Allow.
Introducing this new requirement (and the associated state) in errata
does not seem like a good/practical idea to me because the old servers
would continue to send imprecise Allows. There would be no reliable way
to know whether the reported Allow value obeys the new/fixed semantics.


Received on Friday, 24 June 2005 15:44:33 UTC