Re: HEAD (was Re: Link Verification)

   Date: Thu, 09 May 96 11:59:12 MDT
   From: Jeffrey Mogul <mogul@pa.dec.com>

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

I don't think this makes sense in the case of dynamic documents which
change rapidly.  E.g., a database of realtime information would
generate significantly different results for the same GET request
received minutes apart.

This suggests, to me, the need for some "Dynamic" tag, indicating that
content length, etc. are meaningless.

       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

Joe

Received on Thursday, 9 May 1996 12:48:50 UTC