W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: i24: Requiring Allow in 405 responses

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 04 Mar 2008 16:14:03 +0100
Message-ID: <47CD673B.5000608@gmx.de>
To: John Kemp <john@jkemp.net>
CC: Mark Nottingham <mnot@mnot.net>, "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC