Re: PROPOSAL: i24 Requiring Allow in 405 Responses

On Thu, 2008-03-20 at 15:21 +0100, Julian Reschke wrote:

> RFC2616 says "MUST" advertise (in 405 responses).

Yes.. but it's not entirely clear why this is a MUST.

> I think the concern is 
> that if we relax this to "SHOULD", clients that rely on the presence of 
> the header will break. That is, break in a more fatal way as if the 
> header is there but incomplete.

I very much doubt so for 405. It's not OPTIONS we are talking about
here..

> Note this is already only a "SHOULD" for the OPTIONS responses. As far 
> as I understand, the "Allow on OPTIONS" is the thing clients are really 
> interested in, not "Allow on 405".

Exactly.

And it's valuable to be able to respond with 405 even if you don't qave
full knowledge of the allowed methods. For example in a frontend
intermediary server or web server internal security filter infront of
the actual web application stack.

> (I still have a really hard time understanding why a server ever would 
> be able to state "405 Not Allowed", but not be able to say what would be 
> allowed. Note that 405 != 501.)

Yes, I have also raised this. There is several other status codes one
MAY use if access is denied due to the method used. But it's a SHOULD
level requirement that 405 SHOULD be used.

"Method"

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


> Anyway: do we have any evidence of
> 
> 1) clients failing in *absence* of Allow in a 405 response, and

Can't think of any. Most clients uses OPTIONS and should only get to 405
if they do not care about the Allow result in the first place, or if
there a server configuration error where it includes disallowed methods
in Allow.. (which most likely would bite Allow in 405 as well..)

> 2) servers failing to return Allow in a 405 response?

Quite likely.

> (Henrik, can you check logs...?)

405 is a very rare status code in normal traffic, and the logs I have
access to do not include headers..

But from a quick manual probe based on the handful unique 405's I have
there is some servers not sending Allow in 405 today, as expected.

HEAD http://articles.moneycentral.msn.com/Feeds/RSS/latestrss.aspx

is one..

Regards
Henrik

Received on Thursday, 20 March 2008 20:41:39 UTC