Re: i24: Requiring Allow in 405 responses

Mark Nottingham wrote:
> 
> I think that's the core of the issue, and primary source of confusion.
> 
> There is no "the" set of methods; a single request can only contain one 
> method, so it's impossible to determine what "the" set of methods is; 
> HTTP does not provide atomicity for multiple requests.

That sounds like splitting hairs to me.

The allowed set is the set of methods that was allowed at the time when 
the response was generated.

Yes, there is no cacheability information attached to that, but then 
there's no reason for the client to believe that the set of methods 
*does* change frequently.

Keep in mind that the set of allowed methods is the one that doesn't 
generate a 405 response, not that's going to succeed.

> Therefore, some frame of reference is needed. Most people seem to read 
> "the set of methods" as implying "...that you would accept on this 
> resource" for some undefined, fuzzy period of time, and for some 
> undefined, fuzzy period of request characteristics. The set may contain 
> PROPFIND now, but it may not in three minutes. The set may contain POST 

Why would that ever be the case, except if you reconfigure your server 
not to support PROPFIND? How frequently do these kinds of config changes 
happen?

> if you present the right credentials, but may not if you don't. And so on.

Nope. That's a completely different issue. If your credentials do not 
allow executing a particular method (such as PUT when no write access), 
the answer would be 403; so this has nothing to do with PUT being in the 
"Allow" set.

Yes, this is confusing; so we may want to clarify first what the 405 
status code means.

> Add to this the original concern of the issue; that some implementations 
> may not be able to determine the complete set at runtime.

The original concern seems to be about two things:

- the set of methods may be hard to compute -- a server that says "405" 
but really doesn't know what methods would not generate a 405 seems a 
bit strange to me, but it could still generate something else, like a 
generic 400, or 501.

- you may not want to expose methods to unauthorized clients -- that's a 
very valid concern, so I'd say we just allow the server to make the 
"allow" set depend on the credentials; I don't think this would affect 
any clients in practice.

> In short, the phrase does not include "complete", and the set of methods 
> that it will accept is not necessarily the inversion of the set of 
> methods it won't accept; there is a gray area in between.

Sorry? What would be in that gray area?

> One way to fix this is to make the definition of the set less fuzzy, but 
> as Roy has pointed out, that's taking liberties.
> 
> The other is to document the fuzziness and move on, which is what I'm 
> trying to do. If others have better ways of doing that, or a third way 
> forward, please say so.

It seems to me it would be a good idea to first come up with a common 
understanding when it is correct to return 405, as opposed to 501 or 403.

BR, Julian

Received on Tuesday, 4 March 2008 11:30:07 UTC