Re: i24: Requiring Allow in 405 responses

Hi,

Julian Reschke wrote:
> 
> 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.

As has already been mentioned, that set may vary with each response, 
depending on contextual issues, such as authorization.

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

There is no need for the client to "believe" anything at all is there? 
The client is interested in getting a result, often on behalf of a 
human, who probably doesn't want to see "HTTP/1.1 405 Method Not Allowed".

If the server tells the client that the allowed methods for that 
resource are currently GET and POST and the client gets what it was 
after by using one of those methods, what else is necessary?

[...]

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

In my understanding, 403 indicates that access to the resource is 
currently "Forbidden", not that the method used is not allowed. For 403, 
isn't it the case that the request was found to be formed correctly (ie. 
the resource exists, and the method used on that resource is allowed)?

I think Mark was saying that the server may want to tell the client that 
the method was not allowed, but should also be allowed to return either 
no list, or an incomplete list of allowed methods, depending on whether 
the request contained adequate authorization to receive even this 
additional information.

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

Agreed; that is the case noted above. In other words, the set of ALLOWed 
methods returned might vary between requests to the same resource.

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

I agree with Mark - "document the fuzziness" in the simplest possible 
way, and move on. In my mind, the spec. is "clearly ambiguous" enough 
already, but it seems that others don't see it that way.

The simplest possible change (adding the smallest amount of extra 
ambiguity ;) may be the one-word change I suggested in response to your 
earlier complaint, Julian. But I'm also just fine if we use Mark's 
suggested text.

The spec. is currently ambiguous (there are different interpretations 
possible based on the text, as proven by this discussion), and I think 
it should become no less so - but also the least amount more so.

Regards,

- johnk

Received on Tuesday, 4 March 2008 13:59:19 UTC