Re: i24: Requiring Allow in 405 responses

John Kemp wrote:
> ...
>> 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.

As long as the client sticks to the same credentials, there is little 
reason why it would vary.

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

Nothing.

But if the server does support PATCH, but doesn't include "PATCH" in 
"Allow:", and then the client even doesn't try PATCH because of that, 
that *is* a problem.

>>> 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)?

Yes. That's what you send when the client was authorized, but the 
request is forbidden for the credentials that were given.

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

Not sure I understand this. Seems to be another hint that we need to 
clarify what "405 Not Allowed" means.

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

Possible, but extremely unlikely.

If the client is not authorized at all, and the resource requires 
authentication for the given method, then the right answer is 401 anyway.

If it is authorized, the set of allowed methods will *usually* not vary 
across requests with the same credentials. Why would it?

>>> 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 ambiguities that I see are:

- it's not really clear when to send 405 -- which really is a separate 
issue, and

- the spec only says "the set of methods" in one location.

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

As I have explained (or tried to explain) several times, if we relax the 
server requirement, we *have to* relax the client requirement ("SHOULD 
believe the header") as well.

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

I disagree that there are multiple correct interpretations of what it 
currently says in 14.7. Some confusion is caused by the weaker 
requirement in 10.4.6, so we need to fix that.

Besides that, I'd argue to not break what's in use; thus just warn about 
certain servers not sending a complete list, and taking out the 
requirement on clients not to try anything else.

BR, Julian

Received on Tuesday, 4 March 2008 14:27:23 UTC