Hi Sandford, Sorry, when I said the server returns a different response I wanted to say that the server acts different, thus, doing different (and faster) processing than with a GET request. As an example, a GET request would return an object from the server while a HEAD request would only check if the object exists. The data transferred to the client on a HEAD request will be just the headers, as it should.
When you say XHR objects do not support HEAD, is this true for all cases or only for IE6? We no longer support IE6, so that is not a concern for us. Thank you, Eneko On Sun, May 16, 2010 at 12:18 PM, Sanford Whiteman <[email protected]> wrote: >> We are currently developing a new REST API for our proprietary CMS and >> it will have support for HEAD requests, this is, as you mentioned, the >> server wont process the full request as if it was a GET but return a >> different response instead. > > Hmm, but it shouldn't return a different response. The "spirit" of > HEAD (it is an RFC SHOULD) is that it is identical to a GET for the > same entity, except that only the headers are returned. > > That's why it's more of a convenience method that's most useful when > you don't control the server and you want to make sure that it doesn't > put extra bytes on the wire. If you do control the server (as with > your proprietary platform) there's no advantage over sending a custom > request for /EN/TI/TY/HEAD /EN/TI/TY/FULL etc. > > I agree that it would be nice if Moo supported it (although every XHR > object doesn't -- I think this would break IE 6 BC), but it shouldn't > be a stopping point for your project, since you can wrap the same > functionality in the request parameters. > > -- S. > > -- Eneko Alonso Software Engineer http://enekoalonso.com San Luis Obispo, California
