5 ms·

Is HEAD really used a lot? I don't know that I've ever used it except to try it once. Is it used in API call? If so, why? Thanks for any help on this.

pfraze 13y ago
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 http://tools.ietf.org/html/rfc5988
- lmz 13y ago
  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.
  - pfraze 13y ago
    It's already a pretty chatty protocol; if you can support the HEAD request, why not do so and save the bandwidth?
rjbond3rd 13y ago
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.
cobbal 13y ago
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.
iso-8859-1 13y ago
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!
- sopooneo 13y ago
  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.

pfraze 13y ago

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 http://tools.ietf.org/html/rfc5988

lmz 13y ago
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.
- pfraze 13y ago
  It's already a pretty chatty protocol; if you can support the HEAD request, why not do so and save the bandwidth?

rjbond3rd 13y ago

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.

cobbal 13y ago

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.

iso-8859-1 13y ago

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!

sopooneo 13y ago
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.