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

RE: PROPOSAL: i24 Requiring Allow in 405 Responses

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Thu, 20 Mar 2008 22:03:34 +0100
To: Brian Smith <brian@briansmith.org>
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <1206047014.15894.39.camel@HenrikLaptop>

On Thu, 2008-03-20 at 07:32 -0700, Brian Smith wrote:
> solely because of the method used, then 405 is the most appropriate. I
> would say that the server SHOULD return an Allow header field in its 405
> responses if and only if it can accurately list all of the allowed
> methods.

Same here actually, but it's not a big difference between 405 and 403
here, save for the Allow header requirement. But it is true that 403
does not make any direct claims on what it was with the request that was
unacceptable.

> I totally disagree with you regarding the client side behavior though:
> 
> * The requirements for client processing of 405/Allow do not need to be
> stricter than the requirements for client processing of
> 401/WWW-Authenticate. When the server returns 401/WWW-Authenticate,
> there is nothing that says the client cannot submit the request again
> unchanged; we rely on common sense there, and we can (and should) rely
> on common sense for 405/Allow.

I am not sure the above is true.. it's pretty much implied clients
should stop on 4xx errors and not automatically retry that request. But
I see your point and it has some value.

Common sense here however is that the SHOULD should be followed for the
duration of this transaction or session, not that the client should keep
persistent state information.

> * The SHOULD requirement implies that the client SHOULD maintain state.

Yes.. to a certain degree at least.

> * The SHOULD requirement doesn't have any benefit. The server doesn't
> benefit because still has to be able to handle requests with methods it
> doesn't support.

It's there to indicate that clients should know better than going
against the servers stated intentions as it's most likely a waste to
attempt to do so.

> * Regardless of what the specification says, clients still have to deal
> with servers that do not follow the specification. 

Irrelevant implementation detail. Clients do not have to interoperate
with servers not following specifications.

Regards
Henrik
Received on Thursday, 20 March 2008 21:05:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:37 GMT