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