The main reason I've used it is to fetch content-length and make any necessary provisions (check storage space, warn user, etc.) on the client side before fetching the representation.
In this case you definitely don't want the whole GET response coming at ya. ----- Original Message ----- From: "Adam Taft" <[EMAIL PROTECTED]> To: discuss@restlet.tigris.org Sent: Wednesday, October 3, 2007 4:07:22 PM (GMT-0500) America/New_York Subject: Re: HEAD not well supported? Sean, I agree that HEAD should be supported. Just for the sake of discussion, however, I personally don't find HEAD all that interesting in comparison with Conditional GETs. I mean, when does the client ever just want to "see" if a resource has changed (or exists) without actually retrieving a representation of said resource? That's probably a pretty fringe use case, like some client that's trying to "ping" a resource. Generally, if it makes sense to call HEAD, it usually would make more sense to call GET conditionally, thus saving a hit. I guess HEAD would be useful too if you're not able to send an Etag or Last-Modified date with the representation and the client uses some sort of custom caching mechanism. But, that's not obviously as ideal as using the well supported built-in HTTP caching mechanisms. Oh well, Adam Sean Landis wrote: > So is HEAD too obscure to garner any interest? > > Sean >
