3

I'm trying to debug an issue.

On one of my sites, the font files are not loading correctly. Someone has reported this error in the inspector log:

Font from origin 'http://d1h0r2f9g9fk4d.cloudfront.net' has been 
blocked from loading by Cross-Origin Resource Sharing policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://bit.ly/1Z4W4JZ' is therefore 
not allowed access.

The person who is saying he can't see the font files has also attached this screenshot of the website:

enter image description here

You can see that the fonts (which should be carets are not showing).

In this case, I believe it's font-awesome that isn't loading for him.

  • Cloudfront is the CDN
  • nGinx is the origin (and is correctly sending the Access-Control-Allow-Origin header)

I have performed a curl -v -I and you can see this as the response:

My working response

curl -v -I http://d1h0r2f9g9fk4d.cloudfront.net/static/release/fonts/fontawesome-webfont.ttf?v=4.3.0
* Hostname was NOT found in DNS cache
*   Trying 54.230.149.120...
* Connected to d1h0r2f9g9fk4d.cloudfront.net (54.230.149.120) port 80 (#0)
> HEAD /static/release/fonts/fontawesome-webfont.ttf?v=4.3.0 HTTP/1.1
> User-Agent: curl/7.35.0
> Host: d1h0r2f9g9fk4d.cloudfront.net
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Content-Type: application/octet-stream
Content-Type: application/octet-stream
< Connection: keep-alive
Connection: keep-alive
* Server nginx/1.4.6 (Ubuntu) is not blacklisted
< Server: nginx/1.4.6 (Ubuntu)
Server: nginx/1.4.6 (Ubuntu)
< Date: Wed, 06 Jan 2016 09:33:59 GMT
Date: Wed, 06 Jan 2016 09:33:59 GMT
< Last-Modified: Tue, 09 Jun 2015 10:46:31 GMT
Last-Modified: Tue, 09 Jun 2015 10:46:31 GMT
< ETag: "5576c407-1dcec"
ETag: "5576c407-1dcec"
< Expires: Thu, 04 Feb 2016 18:03:03 GMT
Expires: Thu, 04 Feb 2016 18:03:03 GMT
< Cache-Control: max-age=2592000
Cache-Control: max-age=2592000
< X-Varnish: 2146103981 2146009331
X-Varnish: 2146103981 2146009331
< Age: 55857
Age: 55857
< Via: 1.1 varnish, 1.1 f836ea1710367746c54dbe5fbb422013.cloudfront.net (CloudFront)
Via: 1.1 varnish, 1.1 f836ea1710367746c54dbe5fbb422013.cloudfront.net (CloudFront)
< X-Hashed-On: /static/release/fonts/fontawesome-webfont.ttf?v=4.3.0*cdn.rentivo.com
X-Hashed-On: /static/release/fonts/fontawesome-webfont.ttf?v=4.3.0*cdn.rentivo.com
< X-Discovery: not-set
X-Discovery: not-set
< X-Cache-Lookup: lookup
X-Cache-Lookup: lookup
< X-Cachable: 1
X-Cachable: 1
< Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: *
< X-Cache: Miss from cloudfront
X-Cache: Miss from cloudfront
< X-Amz-Cf-Id: UlVhI7Nix19cnSqakrZ3dqVta9ROM8thQ9c0rixacW-dZpC9wCCe4Q==
X-Amz-Cf-Id: UlVhI7Nix19cnSqakrZ3dqVta9ROM8thQ9c0rixacW-dZpC9wCCe4Q==

< 
* Connection #0 to host d1h0r2f9g9fk4d.cloudfront.net left intact

You can clearly see that Access-Control-Allow-Origin: * is present in the font headers.

I have tried invalidating the Cloudfront distribution, thinking, perhaps the edge server has an old version which did not have these headers, but the person is still saying that he's been unable to view the headers.

I asked him to perform a curl log for me and this was his response.

His failed response

curl -v -I http://d1h0r2f9g9fk4d.cloudfront.net/static/release/fonts/fontawesome-webfont.ttf?v=4.3.0
*   Trying 54.230.149.120...
* Connected to d1h0r2f9g9fk4d.cloudfront.net (54.230.149.120) port 80 (#0)
> HEAD /static/release/fonts/fontawesome-webfont.ttf?v=4.3.0 HTTP/1.1
> Host: d1h0r2f9g9fk4d.cloudfront.net
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Content-Encoding: gzip
Content-Encoding: gzip
< Content-Length: 71646
Content-Length: 71646
< Content-Type: application/octet-stream
Content-Type: application/octet-stream
< ETag: "5576c407-1dcec"
ETag: "5576c407-1dcec"
< Server: nginx/1.4.6 (Ubuntu)
Server: nginx/1.4.6 (Ubuntu)
< Expires: Wed, 03 Feb 2016 10:08:00 GMT
Expires: Wed, 03 Feb 2016 10:08:00 GMT
< Last-Modified: Tue, 09 Jun 2015 10:46:31 GMT
Last-Modified: Tue, 09 Jun 2015 10:46:31 GMT
< Connection: keep-alive
Connection: keep-alive
< Date: Wed, 06 Jan 2016 01:04:10 GMT
Date: Wed, 06 Jan 2016 01:04:10 GMT

< 
* Connection #0 to host d1h0r2f9g9fk4d.cloudfront.net left intact

I CANNOT understand what's happening. Could his ISP be performing some ridiculous snooping/optimization on him? If you notice, the header responses don't even match up. You would at the least expect to see 

< X-Cache: Miss from cloudfront
X-Cache: Miss from cloudfront
< X-Amz-Cf-Id: UlVhI7Nix19cnSqakrZ3dqVta9ROM8thQ9c0rixacW-dZpC9wCCe4Q==
X-Amz-Cf-Id: UlVhI7Nix19cnSqakrZ3dqVta9ROM8thQ9c0rixacW-dZpC9wCCe4Q==

These are all missing.

Does anyone have any insight?

Laykes
  • 431
  • 4
  • 14
  • Something definitely does not add up. A cached response from CF should also have an `Age:` header. What if they request from CF over https? `*.cloudfront.net` (as you probably know) has a wildcard cert. HTTPS should stop naive ISP snooping/tweaking, which is what I am inclined to suspect, here. My next step would be enabling CloudFront logs, if not already done, so you can confirm whether each request actually arrives at CF from the user. – Michael - sqlbot Jan 06 '16 at 14:14
  • Although I am not inclined to suspect a bug in CloudFront, the presence of `Content-Encoding: gzip` in one response but not the other prompts me to ask whether you have enabled the new [on-the-fly gzip compression feature](https://aws.amazon.com/blogs/aws/new-gzip-compression-support-for-amazon-cloudfront/) in CloudFront. While unlikely, this needs to be checked. It's also possible the the far-end ISP is doing gzipping and/or caching, and their implementation is broken. – Michael - sqlbot Jan 06 '16 at 14:24

1 Answers1

3

Late response but stumbled across this thread while struggling with the same problem.

Try adding an Origin header to your curl request; this fixed it for me - something like: 

curl -v -I "http://d1h0r2f9g9fk4d.cloudfront.net/static/release/fonts/fontawesome-webfont.ttf?v=4.3.0" -H "Origin: https://example.com"
David Harrison
  • 31
  • 2