Juha-Matti Tapio wrote:
On Wed, Aug 10, 2005 at 10:08:08PM +1000, Graham Dumpleton wrote:
Okay. What though are the implications of content still being returned
for a HEAD request. What does the standard say about that?
RFC 2616, 9.4 HEAD
The HEAD method is identical to GET except that the server MUST NOT return
a message-body in the response. The metainformation contained in the HTTP
headers in response to a HEAD request SHOULD be identical to the
information sent in response to a GET request.
Ok, now that I read the standard again, it seems that the preferable way to
implement this is to somehow prevent the bytes written from being sent.
Though I have no idea how the user agents would react if they did receive
a message body on HEAD.
It defeats the purpose of HEAD for starters, ie wastes bandwidth. If the
user agent is making use of HEAD and gets stuffed with a large download
each time - well that can't be good for performance. ;)
To save everyone looking it up here is the full section 9.4
http://www.rfc.net/rfc2616.html#s9.4
9.4 HEAD
The HEAD method is identical to GET except that the server MUST NOT
return a message-body in the response. The metainformation contained
in the HTTP headers in response to a HEAD request SHOULD be identical
to the information sent in response to a GET request. This method can
be used for obtaining metainformation about the entity implied by the
request without transferring the entity-body itself. This method is
often used for testing hypertext links for validity, accessibility,
and recent modification.
The response to a HEAD request MAY be cacheable in the sense that the
information contained in the response MAY be used to update a
previously cached entity from that resource. If the new field values
indicate that the cached entity differs from the current entity (as
would be indicated by a change in Content-Length, Content-MD5, ETag
or Last-Modified), then the cache MUST treat the cache entry as
stale.
Interestingly, section 5.1.1 says that "The methods GET and HEAD MUST be
supported by all general-purpose servers.", so it would seem that
mod_python has not been compliant to the RFC.
http://www.rfc.net/rfc2616.html#s5.1.1
5.1.1 Method
The Method token indicates the method to be performed on the
resource identified by the Request-URI. The method is case-sensitive.
Method = "OPTIONS" ; Section 9.2
| "GET" ; Section 9.3
| "HEAD" ; Section 9.4
| "POST" ; Section 9.5
| "PUT" ; Section 9.6
| "DELETE" ; Section 9.7
| "TRACE" ; Section 9.8
| "CONNECT" ; Section 9.9
| extension-method
extension-method = token
The list of methods allowed by a resource can be specified in an
Allow header field (section 14.7). The return code of the response
always notifies the client whether a method is currently allowed on a
resource, since the set of allowed methods can change dynamically. 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. All other
methods are OPTIONAL; however, if the above methods are implemented,
they MUST be implemented with the same semantics as those specified
in section 9.
Regards,
Jim
