maybe i'm missing something, but it seems that calling HEAD on a zope url does not invoke acquisition. e.g.: if i have the following objects: /foo content header /foo/bar content then get HTTP 200 for the following calls: GET /foo/bar/content GET /foo/content GET /foo/header HEAD /foo/content HEAD /foo/header But I get HTTP 404 if i call HEAD /foo/bar/header This seems wrong since the document appears to be there under one method and appears to not be there in the other. Is this acceptable in terms of the HTTP RFC? I haven't checked. I can't think of any reason for this although perhaps ZC did. Best, Mark mlogan@ccs.neu.edu
Mark Logan wrote:
maybe i'm missing something, but it seems that calling HEAD on a zope url does not invoke acquisition. [...] This seems wrong since the document appears to be there under one method and appears to not be there in the other. Is this acceptable in terms of the HTTP RFC? I haven't checked.
Nope, from the http/1.1 rfc 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. And this should indeed be fixed, because some search engines and monitoring tools and even browsers (icab/mac, mozilla) indeed seem to use HEAD for purposes stated above. I just grepped one log-file from a server and found various hits with HEAD ~180 in november alone. cheers, oliver
participants (2)
-
Mark Logan -
Oliver Bleutgen