The Web Linking RFC [1] uses it to do discovery. The HEAD is mainly used to get ahold of the "Link" response header.

    > HEAD / HTTP/1.1
    < 204 no content
    < Link: <foobar.com/>; rel="self service"; title="Foobar!",
            <foobar.com/users>; rel="collection"; id="users"

    > HEAD /users HTTP/1.1
    < 204 no content
    < Link: <foobar.com/>; rel="up service"; title="Foobar!",
            <foobar.com/users>; rel="self collection"; id="users"
            <foobar.com/users/bob>; rel="item"; id="bob"

    > GET /bob HTTP/1.1
    ...

GET can't support that process, so that's just one reason why I'm against ditching the extra verbs.

1 http://tools.ietf.org/html/rfc5988

Why can't GET support that process? You'd have the extra bytes of the content, but there's nothing stopping the server sending the Link header in response to a GET request.

It's already a pretty chatty protocol; if you can support the HEAD request, why not do so and save the bandwidth?

Yes, it's used a lot. If you look through web server logs, you'll see tons of cases where a search engine spider performs a HEAD, and then based on the headers, it decides whether the content has changed since last fetched. If so, it issues a GET.

Say you have a list of downloads, and you want to know how big they are. With HEAD and Content-Length, you can know, in a standard fashion, assuming the server tells you. Isn't this basic enough, that you'd want to put it in HTTP? What else would you do? Application-specific file-size queries? Doing a GET and then just closing the connection after headers? That's not pretty!

That makes sense. I was not challenging the inclusion of HEAD in the http verbs, just stating my own ignorance and hoping for illumination, which you and others and have now provided. I appreciate it.

personally I use HEAD quite often in the form of `curl -I` if I want to check the size or mime type of a particular resource.