At Sat, 6 Oct 2007 18:40:36 +0200, "Jerome Louvel" <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm a bit late in the discussion it seems :) > > Let me try to explain how the support for HEAD was designed in Restlet. > Following the definition of HEAD from the HTTP spec [1], I got convinced > that HEAD was only a special GET and nothing more: > > "The HEAD method is identical to GET except that the server MUST NOT return > a message-body in the response." > > In order to fulfill this requirement, the framework expects you (Resource > and any Restlet/Filter/etc.) to return the exact same response as you would > for the similar GET request. > > The trick is that at the HTTP server connector level, we never send back the > response's entity content for HEAD requests.
So during the lifecycle of a HEAD request we should never get a call to the write/getStream/getChannel/toString methods of a Representation? If so, a lazy initialization of representation content should be possible. > However, we do need the full Representation because some metadata are not > part of the Variant information per se. I know in Restlet 1.0 the Variant > class do have the "size" property but that was a mistake that we fixed in > version 1.1 (trunk) by moving the property down to the Representation class > (subclass of Variant). The same was done for the "Expiration Date", > "ModificationDate" and "Tag" properties. Looking at the code, I expected that Variant had all those properties to allow for it to be sufficient for a HEAD request, so I was confused that HEAD would use a representation; but this makes sense. > Also, the Finder class calls the Resource.allowGet() method for both GET and > HEAD requests as there is no reason (following the HTTP spec intent) to > differentiate GET and HEAD request in this regard. > > I'm still convinced that current design is appropriate. I would even go > further by removing the Resource.handleHead() method and make the Finder > class call handleGet() directly instead. > >[…] Not my place, perhaps, but I am agreed. best, Erik ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3
pgpzsSzGTaVM2.pgp
Description: PGP signature
