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

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 23 Jun 2005 14:00:23 -0700

In RFC 2616:

10.4.6 405 Method Not Allowed

    The method specified in the Request-Line is not allowed for the
    resource identified by the Request-URI. The response MUST include an
    Allow header containing a list of valid methods for the requested
    resource.

which has the effect of requiring that a server advertise all
methods to a resource.  In some cases, method implementation is
implemented across several (extensible) parts of a server and
thus not known.  In other cases, it may not be prudent to tell
an unauthenticated client all of the methods that might be
available to other clients.

I think the above should be modified to s/MUST/MAY/; does anyone
here know of a reason not to make that change?

....Roy

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 23 Jun 2005 17:04:05 -0600

On Thu, 2005-06-23 at 14:00 -0700, Roy T. Fielding wrote:
> methods to a resource.

The MUST requirement does not say "a list of ALL valid methods", but
perhaps that is implied.

>   In some cases, method implementation is

RFC 2616 says that "the methods GET and HEAD MUST be supported by all
general-purpose servers". Thus, a general-purpose server (whatever that
is) can satisfy the above MUST by listing GET and HEAD in the Allow
header. Note that unauthorized requests can be denied, if needed.

Said that, I suspect that changing this MUST to SHOULD or MAY will not
have a negative impact on implementations.

Alex.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 23 Jun 2005 16:24:12 -0700

> The MUST requirement does not say "a list of ALL valid methods", but

It is implied by the definition of the Allow header field, which
serves no purpose whatsoever if it does not include all of the
methods supported by the resource.  It is better to not send the
field rather than send an inaccurate field value.

....Roy

---

From: Yves Lafon <[email-masked]>
Date: Fri, 24 Jun 2005 12:08:06 +0200 (MEST)

> The MUST requirement does not say "a list of ALL valid methods", but

Note that in 5.1.1
<<<
An origin server SHOULD return the status code 405 (Method Not Allowed) if 
the method is known by the origin server but not allowed for the requested 
resource, and 501 (Not Implemented) if the method is unrecognized or not 
implemented by the origin server.

So if the server needs to hide something to an authenticated requester, it 
may not user 405 but something else (403?)

>> thus not known.  In other cases, it may not be prudent to tell

For this case, how about slightly modifying the definition of Allow in 
14.7 to say that the list of method may be incomplete?

> have a negative impact on implementations.

Indeed, but it does not prevent fixing other parts of the RFC as well.
Thanks,

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 24 Jun 2005 09:41:57 -0600

On Thu, 2005-06-23 at 16:24 -0700, Roy T. Fielding wrote:
> 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
> 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

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

Alex.