Wondering when to use HEAD over GET ?

I definitely underestimated the power of HEAD method requests, until I landed myself into a performance trouble. So here I am to share my learning with you all in this blog post.

As you would already know, a GET method retrieves the information in the form of an entity identified by the request URI. And HEAD method is a slight modification to the GET method with all response headers and no message body response. HEAD methods are safe, idempotent and cacheable just like the GET methods.

HEAD or GET method for your use-case ?

If your objective is any of the following :

• Check if content is available or has changed at the request URI.
• Check if the request URI supports any other protocol.
• Know when the response cache is going to expire, so that you can request new content after expiration.

Then, go ahead with the novel HEAD method request. In fact, anywhere you don’t care about the actual response body and just the metadata then HEAD is your ultimate solution.

Since the HEAD method provides us with the information of content-length in bytes , content-type , cache-control etc, we can easily meet our above mentioned objectives without paying for the bandwidth which is otherwise the case with GET requests. And this bandwidth can be extremely large when the request URI serves an audio or a video content.

Sample response header for a HEAD method request

So does it mean that HEAD method requests are light requests for servers too? No, unfortunately not. Since the server has to return content-length in the response header, it needs to generate the response body and calculate the length.

Performance improvement with HEAD

Usually the performance improvement between a HEAD and a GET method is very negligible when server is fast with the response and the message body is small. But the absolute game changer is, when the response message body is a huge download and hence takes time to respond.

Here comes my use-case, I just want to check if an audio url is resolvable. So, this is a sample GET method request which should return an audio file (It’s one of my disliked podcast 😄). As you see it took about 1.5 seconds to load for a content of size is 13.6 Mb.

But wait! Do I even care about the actual content? Hell, No. So lets switch to HEAD.

Noice! So now I see an improvement. It gave me what I needed in much lesser time saving my bandwidth in under 500 ms. Now let’s see its overall impact on the system in terms of CPU and memory usage.

CPU usage comparison with GET until 5th March morning and HEAD from 5th March evening

Memory usage comparison with GET until 5th March morning and HEAD from 5th March evening

So, HEAD is a clear WINNER!

Do all GET resources support HEAD method by default ?

No, it’s not necessary but it’s recommended as per HTTP standards. Where it mentions -

All general-purpose servers MUST support the methods GET and HEAD.
All other methods are OPTIONAL.

With Spring Web MVC, all the @RequestMapping for GET methods are implicitly mapped to and support HEAD. So by default all GET methods support HEAD as well. However you are free to provide any custom implementation for HEAD methods as per your use-case.

I hope this blog post gave you some clarity on the topic. If you have any question, then please feel free to drop them in the comments section.

Cheers!