What if I told you there exists a simple method to start saving money on servers today and that takes only one line of code to implement would you believe me?
Well welcome to the world of headers, for followers of my blog this is more like an expansion of what we had talked about a few months ago Using status codes and headers
In this entry we are going to talk about the headers that we can start using to reduce server-client communication immediately which has the double benefit of
- Saving your customers especially those on mobile data charges
- Reducing the work your server needs to do
The Etag provides a unique representation of the response issued by the server. It is usually a short string that is of meaning to the server. You probably already have unique ids for data entries in your application, this would act as good targets for an etag if however entries are editable you may choose to use a hash of the content.
\\Code example in Laravel PHP $etag=md5($content); return response($content) ->header('Etag', $etag);
An Etag is not of much use if the client doesn’t make use of it. The If-None-Match header allows the server to return appropriate responses for the data if content still there.
use GuzzleHttp\Psr7\Request; // Create a PSR-7 request object to send $headers = ['If-None-Match' => '897696a7c876b7e']; $request = new Request('GET', 'http://yourservice/blogs/57', $headers, $body);
This instructs the client and all other downstream services if the content can be cached.
The main settings for it include:
- private Instructs cache is specific to a user
- public Can be cached for use by all clients
- no-cache Client must re validate all requests
- no-store Client should not cache anything at all
There are more settings and you should check them out http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
return response($content) ->header('cache-control', 'private, no-cache');
Nothing lasts forever, even data. As such makes sense to inform clients of best by date for the data they have cached. In modern browsers you could use max-age control in the cache-control header.
#Example for django response = HttpResponse() response['Expires'] = "Thu, 24 Sep 2015 12:00:00 GMT"
As you get more sophisticated in your caching techniques it may now be time to start using the Vary header. The header allows clients to know if they have valid content based on some condition.
The most obvious example would be if you serve different content for mobile and notebooks then the browser should first check if the cached content is of the same user agent
#Example for ROR response.headers["Vary"] = "User-Agent"
It is important to note that not all clients respect headers but for those who do, you would be doing yourself and them a world of favor by providing them with appropriate headers
Will you be implementing the headers we have talked about? Talk to us on the comment section below.