Subject: GET/HEAD support "MUST"

From: Geoffrey Sneddon <[email-masked]>
Date: Wed, 28 Jan 2009 19:01:01 +0000

Hi,

Both RFC2616 and bis both include the following:
> The methods GET and HEAD MUST be supported by all general-purpose  
> servers.

This is unclear for several reasons:

a) Although the server MUST support those two methods, MUST it support  
it for every resource?

b) What is a "general-purpose server"? This is the only time this  
phrase occurs within RFC2616, with nothing to say what it refers to.

I mention a) because a large number of web forms create a special  
resource to send submissions of the form to. Inevitably, if that form  
is to be sent via POST, a GET request of that resource makes little  
sense.

--
Geoffrey Sneddon
<http://gsnedders.com/>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Jan 2009 21:23:19 +0100

> a) Although the server MUST support those two methods, MUST it support 

Dunno.

> b) What is a "general-purpose server"? This is the only time this phrase 
> occurs within RFC2616, with nothing to say what it refers to.

Dunno.

> resource to send submissions of the form to. Inevitably, if that form is 
> to be sent via POST, a GET request of that resource makes little sense.

I guess the intent of this language is to ensure that any server that 
implements HTTP must be prepared for GET/HEAD requests on any URI.

That being said, it's probably sufficient that a special resource as 
described above just returns 401 or 501 -- so doing a retrieval never 
ever would cause a side-effect.

Mark, should we add that as editorial issue to the list?

BR, Julian

---

From: "William A. Rowe, Jr." <[email-masked]>
Date: Thu, 29 Jan 2009 15:08:02 -0600

>> a) Although the server MUST support those two methods, MUST it support

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.

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.

It's probably a good idea to implement them, in a write-only server they
could consistently return 404.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Jan 2009 22:56:16 +0100

> anything except GET is not valid.  Implementing GET without HEAD is not

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.

> HEAD would be 404 not found.

Indeed.

> could consistently return 404.

That's probably the safest approach.

BR, Julian

---

From: Dan Winship <[email-masked]>
Date: Thu, 29 Jan 2009 17:28:59 -0500

> That's probably the safest approach.

I was thinking the "general purpose server" comment was meant to allow
for things like having an HTTP server that's only there to provide an
XML-RPC interface to something. Since XML-RPC only uses POST, there'd be
no reason for it to support GET/HEAD, but since it only expects to talk
to XML-RPC clients, not HTTP clients in general, it wouldn't be a
"general purpose server", so returning 501 for GET/HEAD would be
perfectly reasonable.

-- Dan

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Jan 2009 23:31:34 +0100

> "general purpose server", so returning 501 for GET/HEAD would be

Yes, that's what I would assume as well.

The only really really important thing is that

- the server doesn't misinterpret GET as POST, and

- it understands that HEAD == GET minus the response body.

BR, Julian

---

From: "Robert Brewer" <[email-masked]>
Date: Thu, 29 Jan 2009 15:26:07 -0800

> 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
[email-masked]

---

From: "William A. Rowe, Jr." <[email-masked]>
Date: Thu, 29 Jan 2009 18:13:54 -0600

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

There are several reasonable answers;

  403 - the server prohibits GET/HEAD against this (all) URI(s)
  404 - the server has nothing to offer (a write-only server)
  405 - the server prohibits method GET/HEAD (might confused some clients)

There's clearly a wrong answer per your snip above;

  501 - not implemented

The other 500 codes imply to the client that it could retry at some future
time, which of in this case is an untrue assertion.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 30 Jan 2009 18:56:52 +1100

Yes, editorial is fine unless someone feels strongly.

My assumption is that this was written when it was desirable to  
encourage servers to implement GET and HEAD, and not just POST (I  
guess). That's been achieved, so I think it's safe to remove this  
requirement.

Stating that any resource that supports GET MUST also support HEAD  
seems like a good thing, if it already hasn't been said.

Cheers,

On 30/01/2009, at 7:23 AM, Julian Reschke wrote:

>> a) Although the server MUST support those two methods, MUST it  
>> support it for every resource?
>
> Dunno.
>
>> resource to send submissions of the form to. Inevitably, if that  
>> form is to be sent via POST, a GET request of that resource makes  
>> little sense.
>
> I guess the intent of this language is to ensure that any server  
> that implements HTTP must be prepared for GET/HEAD requests on any  
> URI.
>
> described above just returns 401 or 501 -- so doing a retrieval  
> never ever would cause a side-effect.
>

--
Mark Nottingham     http://www.mnot.net/

---

From: "Robert Brewer" <[email-masked]>
Date: Fri, 30 Jan 2009 10:33:38 -0800

William A. Rowe, Jr. wrote:
> > 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").
> 

Thanks for the correction. I didn't believe you at first ;) but your post prompted me to do a bit of digging and I found lots of support for 404. Somehow I was under the impression that a 404 response code meant "no such resource" when it's better to say it means "no such representation" [1][2]. In fact, the response entity in that case is "a representation of a 404 response" [3]. For anyone who was misguided as I was, read the links below. ;)

I think I'd still prefer the more-specific "405" in most cases to the catch-all "404". But I can see how 404 is a valid response, and might be preferred for maximizing interop with clients, some of which may not gracefully deal with 405.

Robert Brewer
[email-masked]

[1] http://markmail.org/message/jfyiebtqhl4wlsme
[2] http://lists.w3.org/Archives/Public/uri/2004Jun/0006.html
[3] http://markmail.org/message/54jr3v2s5uy7jjzx

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 31 Jan 2009 10:30:21 +1100

One quick comment -

On 31/01/2009, at 5:33 AM, Robert Brewer wrote:
>
> I think I'd still prefer the more-specific "405" in most cases to  
> the catch-all "404". But I can see how 404 is a valid response, and  
> might be preferred for maximizing interop with clients, some of  
> which may not gracefully deal with 405.

There's a very fine (sometimes invisible) line between accommodating  
the realities of implementation (i.e., making things work), and  
dumbing down the protocol to the lowest common denominator.

Trying to anticipate where clients *may* not handle something  
correctly errs too far on the side of the latter, I think. Without  
hard and compelling evidence, I'd be inclined to go with your  
preference.

Cheers,