- From: Robert Brewer <fumanchu@aminus.org>
- Date: Thu, 29 Jan 2009 15:26:07 -0800
- To: "Julian Reschke" <julian.reschke@gmx.de>, "William A. Rowe, Jr." <wrowe@rowe-clan.net>
- Cc: "Geoffrey Sneddon" <foolistbar@googlemail.com>, "HTTP Working Group" <ietf-http-wg@w3.org>
Julian Reschke wrote: > William A. Rowe, Jr. wrote: > >>> a) Although the server MUST support those two methods, MUST it > support > >>> it for every resource? > >> Dunno. > > > > It must support them in tandem. Implementing HEAD that corresponds > to > > anything except GET is not valid. Implementing GET without HEAD is > not > > valid either. > > Right. This is so hardwired into my brain that I didn't even consider > this being not clear. We probably should add a statement about that to > the description of the GET method. > > > Nothing says a resource must support them, however. E.g. PUT to a > specific > > URI might be valid, but there is no resource yet before PUT, ergo GET > and > > HEAD would be 404 not found. > > Indeed. > > > It's probably a good idea to implement them, in a write-only server > they > > could consistently return 404. > > That's probably the safest approach. An origin server SHOULD return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD MUST be supported by all general-purpose servers. I think that pretty clearly states that, for GET and HEAD, 405 is the recommended approach, not 404. Other methods may alternately use 501. The only case I can think of for 404 is if the resource identified by the Request-URI doesn't implement *any* method (or, saying that a different way, "if there is no resource identified by that Request-URI"). Robert Brewer fumanchu@aminus.org
Received on Thursday, 29 January 2009 23:26:49 UTC