At 11:37 PM +0000 10/3/07, Sean Landis wrote:
Here's an interesting follow-up. I have a resource that only implements GET
and returns "Ok". As the code implies, a HEAD request will do just like
GET.
When I run: curl --request head <my-url>
It blocks until timeout and then prints:
curl: (18) transfer closed with 2 bytes remaining to read
So it seems the esteemed tool, curl, totally expects HEAD to not return
any content.
Interesting. It may be that cURL is simply following the spec.
From the RFC for HTTP 1.1:
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4> (or
for the purist, section 9.4 in <http://www.ietf.org/rfc/rfc2616.txt>
:-):
The HEAD method is identical to GET except that the server MUST NOT
return a message-body in the response.
Would this also imply that the correct HTTP Status code to be
returned from a HEAD request should be 204, corresponding in the
Restlet framework to something like getResponse().setStatus(
Status.SUCCESS_NO_CONTENT )?
That type of response is described in the Restlet Javadocs, with
some language borrowed from the RFC's formal description, as:
The server has fulfilled the request but does not need to return an
entity-body (for example after a DELETE), and might want to return
updated metainformation.
Aron Roberts Information Services and Technology . 2195 Hearst
University of California, Berkeley, CA 94720-4876 USA
[EMAIL PROTECTED] . +1 510-642-5974 . fax 510-643-5385
http://purl.org/net/aron
