June 29, 2016
In some cases it will be assumed that your end users are sending request headers to the CDN – regardless of whether it’s a full site cache or straightforward CDN (static file delivery).
In cases when we can see the request headers on the server side is when the browser requests a file and carries with it the request header (requesting condition). This header is setting the rule for the server so it knows what condition the browser is expecting the file by.
One common request header is “Content-Type” and, based on the file type, this value will change (Ex: image.png -> Content-Type: image/png).
One new format introduced to the list of image format types is WebP.
As an example, to load a WebP variant of “image.png” you would send the modified content type header asking for the “image/webp” image type. Of course you won’t be sending this request, but your browser that supports WebP will. The browser that supports WebP will try to load the WebP variant first and then failover to the original image file type.
Examples of Requests
How would the response change based on request headers? This time we want the same URL only without compression. To do this, we’ll use the console to make the request with and without compression and see what happens.
With compression requested:
$ curl -I 'https://www.maxcdn.com/one/wp-content/themes/maxcdn_one/assets/css/style.css' HTTP/1.1 200 OK Content-Type: text/css Content-Length: 93934 Cache-Control: max-age=604800 Vary: Accept-Encoding Access-Control-Allow-Origin: * Server: NetDNA-cache/2.2 X-Cache: HIT Accept-Ranges: bytes
Without compression requested:
We can see from the last response that Vary is based on “Accept-Encoding” so we’ll use this request header to request the compressed version of this file.
$ curl -I 'https://www.maxcdn.com/one/wp-content/themes/maxcdn_one/assets/css/style.css' -H 'Accept-Encoding: gzip' HTTP/1.1 200 OK Content-Type: text/css Cache-Control: max-age=604800 Vary: Accept-Encoding Server: NetDNA-cache/2.2 X-Cache: HIT Content-Encoding: gzip
This is great, but how can we extend this to custom scenarios where the request header would affect CDN cache or edge server behavior?
First, let’s define a scenario we want to achieve.
A common case is the access control based on a request header, so we’ll set the edge rule that will grant access to files only with the proper “Origin” header in the request for dynamic files. This means that when you request a dynamic file (php for example), you should have the proper “Origin” header set to the value of your origin domain (domain.com).
Nginx allows you to grab the value of a certain request header by simply asking for the value of “http_HEADER_NAME”. In our case with the “origin” request header, we’d look into “http_origin” variable:
CURL Cxample with Proper “Origin” Header
$ curl -I http://cdn.domain.com/ -H 'origin: domain.com' HTTP/1.1 200 OK Date: Fri, 18 Sep 2015 20:53:58 GMT Content-Type: text/html Content-Length: 935 Connection: keep-alive Last-Modified: Thu, 06 Aug 2015 12:32:59 GMT Vary: User-Agent,Accept-Encoding Pragma: public Cache-Control: public, must-revalidate, proxy-revalidate X-Content-Type-Options: nosniff Server: NetDNA-cache/2.2 X-Cache: HIT Accept-Ranges: bytes
CURL Example Without Proper “Origin” Header
$ curl -I http://cdn.domain.com/ HTTP/1.1 403 Forbidden Date: Fri, 18 Sep 2015 20:54:12 GMT Content-Type: text/html Content-Length: 169 Connection: keep-alive Server: NetDNA-cache/2.2