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 the WebP format 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 Example 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
If you have any questions or experience any issues, please reach out to the Support Team, live chat and ticket support are available 24/7.