Re: i24: Requiring Allow in 405 responses

Julian Reschke wrote:
> 
> John Kemp wrote:

[...]

>>
>> 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 the client *wants* or *needs* to try PATCH, then it can, regardless 
of what the server has or has not told it. If it gets a 405 in return, 
then it probably wouldn't want to try that again.

[...]

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

Possible, though.

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

If the client doesn't present credentials at all when making an initial 
request, the server may not be willing to present it with any additional 
status information in a 405. If the client later does acquire 
authorization credentials (perhaps during access to another resource) 
and then accesses the same resource for which it earlier received a 405, 
then the resulting response may now contain more information.

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

My understanding of SHOULD is that it is not MUST.

I imagine a client will often simply try a method that it needs to use 
anyway.

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

OK - I can agree on the warning (I guess that's more or less Mark's text?)

But the SHOULD already doesn't prevent a client from trying something it 
needs to (and will not unless it became a MUST). And that SHOULD *does* 
give the impression that the client should listen to the server, and 
that the server should not deceive the client. That all seems fine and 
proper.

Cheers,

- johnk

> 
> BR, Julian
> 
> 
> 
> 
> 
>

Received on Tuesday, 4 March 2008 14:49:34 UTC