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. 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. 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. Still, I'm always open for discussion! Best regards, Jerome [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4 > -----Message d'origine----- > De : news [mailto:[EMAIL PROTECTED] De la part de Sean Landis > Envoyé : vendredi 5 octobre 2007 21:43 > À : discuss@restlet.tigris.org > Objet : Re: HEAD not well supported? > > In Summary... > > It sounds like folks are in agreement that HEAD is not > properly supported but > I haven't heard from Jerome or Thierry, etc. What do you guys think?
