Re: i24: Requiring Allow in 405 responses

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

Many clients try to present a UI to their user, disabling things that 
are known not to work. So being able to find out whether a resource 
supports a specific method is a useful feature.

Yes, this does not apply to all clients, but that doesn't mean we can 
just get rid of it.

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

But that makes a big difference. When, in general, the information is 
reliable, clients are going to use it.

When, in general, it is unreliable, clients will ignore it.

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

My point was that in this case 405 is already a bad choice. And if the 
status code is not 405, the whole discussion is pointless.

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

Yes. One more reason not to use 405 in the first case.

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

That is correct but not really helpful.

A spec that says "servers MAY lie" but "clients SHOULD trust them" makes 
a very bad use of RFC2119 terminology.

If we want to *allow* servers to return incomplete lists, we simply can 
not say "SHOULD follow that list".

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

Yes, that's one way to things. Clients that work this way ignore 
"Allow:" anyway.

What I am interested in are clients that *do* use the value, for 
instance, in order to populate a UI.

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

Doesn't work for me. We can't have a "SHOULD use" for information we 
allow to be broken.

If we make changes, let's do so in a consistent way, please.

BR, Julian

Received on Tuesday, 4 March 2008 15:14:18 UTC