Re: HEAD (was Re: Link Verification)

    >In other words, I think the correct action for your server to take
    >for a HEAD request is to generate whatever it would generate for
    >a GET request, but then just drop the entity-body on the floor.

    I think that there is a large range of active content for which
    this model fails. If the server is never going to generate the same
    entity twice then it is pointless telling the client the content
    length, digest or any other parameter of the content which would
    not be the same for a subsequent HEAD.

Well, the point is that when the client sends the HEAD request,
it doesn't know if the result is pointless or not.

We seem to have several choices:

	(1) return an error for resources where HEAD would return
	something different each time.
	
	(2) return exactly what a GET on the resource would return,
	except not send any content.

	(3) something else?  that might be hard to specify

It seems to me that #2 is the simplest to specify: "HEAD is exactly
the same as GET but does not return an entity body".  Which is what
the current draft says.

    Does the spec specifically require a HEAD method to return content
    length? If not simply returning the entity content type would
    appear to be sufficient.

I think it's ambiguous on this point.  The description of Content-Length
says

    The Content-Length entity-header field indicates the size of the
    Entity-Body, in decimal number of octets, sent to the recipient or,
    in the case of the HEAD method, the size of the Entity-Body that
    would have been sent had the request been a GET.

but I can't find a statement that says that Content-Length is mandatory
on a HEAD response, since it isn't mandatory on a GET response
(i.e., if one is using a chunked encoding).

HEAD responses would presumably also return the Last-Modified
header and/or Etag header, which might be useful to a client that
wishes to know if its current cache entry is valid.

    Leaving asside the statement in the HTTP/1.0 spec the strict
    condition of idempotence which Tim originaly stated has never been
    absolute.  For example in my email server I updated the "read"
    condition of a message when it was accessed via a GET method but
    not when it is accessed by a HEAD. This is well within the spirit
    of the "safe GET" but it isn't idempotent.

    I think it better to consider the HEAD method as strictly a means
    of retrieving whatever meta information concerning an entity may be
    avaliable.

This may be a reasonable approach to take, but I can't see anything
in the current spec that would suggest that the side-effect semantics
of HEAD can or should be different from those of GET.  Section
13.3 says "The HEAD method is identical to GET except" for the lack
of an entity body in the response.

There is one thing that bothers me about this section: it also says
that 
	There is no "conditional HEAD" [...] request analogous to
	those associated with the GET method.  If an If-Modified-Since 
	[...] header field is included with a HEAD request, [it]
	SHOULD be ignored.

This would not be an issue of GET and HEAD never had any side
effects at all, as 19.2 sort-of requires.  But in the real world,
we know that some servers do implement side-effects for GET,
and one possible use of a conditional GET is to prevent such
side effects if the condition isn't true.  So it seems reasonable
to allow a client to send a conditional HEAD, and define this
as identical in effect to a conditional GET (except that it returns
no entity body in any case).

-Jeff

Received on Thursday, 9 May 1996 12:13:13 UTC