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.

Image Example

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.

Important: For you to take advantage of WebP, your server needs to support it and have variants of your images ready for delivery.

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.

Note: We do not honor Vary in a conventional way, but are using this response as an indicator based on which request header can get a different response.
$ 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