Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

With the following response header:

HTTP/1.0 200 OK
Content-Type: video/mp4
Content-Length: 3294545
Connection: keep-alive
Date: Thu, 30 May 2013 21:17:34 GMT
x-amz-meta-s3cmd-attrs: uid:501/gname:staff/uname:americanyak/gid:20/mode:33
    152/mtime:1368215923/atime:1369948577/ctime:1
    369948245
Cache-Control: no-transform,public,max-age=31536000,s-maxage=31536000
Expires: Fri, 30 May 2014 00:00:00 GMT
Last-Modified: Thu, 30 May 2013 21:16:39 GMT
ETag: "b524b3f434581a1c2daff863cf201540"
Accept-Ranges: bytes
Server: AmazonS3
Age: 1309
Via: 1.0 33c069541cbb3f6e68de8056c044d86e.cloudfront.net (CloudFront)
X-Cache: Hit from cloudfront
X-Amz-Cf-Id: oeZ3EzRFAZggWpgqIbObtJH_MdyrGLMsdxUU3amupI5rkq7sbXPt4A==

What am I missing? Why is this not caching?

share|improve this question

https://forums.aws.amazon.com/thread.jspa?threadID=124998

Hello,

While we are aware of the issue with range request HTTP/1.0 206 responses and Chrome, we cannot provide an ETA for a fix. Since this issue is specific to range requests, an immediate workaround is to disable range requests on your origin server if this is possible for your use case.

It is also worth mentioning that multiple web proxy and cache application vendors have using HTTP/1.0 as a de facto standard for many years, so you will probably sporadically get similar reports from your end users using Chrome, but not other browsers such as Firefox or Safari. For example, here is a discussion between a Chrome developer on the mailing list for the popular Squid web cache about a similar report: http://www.squid-cache.org/mail-archive/squid-dev/201204/0113.html I am not saying that always returning HTTP/1.0 will stick around forever, but it is fairly common in real world situations today.

We are working on a fix for the future.

Regards,

Matt J

share|improve this answer
    
They could implement HTTP/1.1. It's only 14 years old now! – Michael Hampton May 30 '13 at 23:18

I was able to work around the issue by disabling the ETag header on my origin server.

CloudFront doesn't like ETag references for some reason.

To this day, requests sent with the Range header for video/mp4 files via CloudFront cause the entire object to be returned with 200 OK instead of 206 Partial Content when the client sends an If-Range header with a cached ETag reference.

Removing the ETag header from the origin server effectively works around the issue, as the client will no longer send If-Range, and CloudFront will return 206 Partial Content as expected.

Also, it will prevent cache misses (X-Cache: Miss from cloudfront), saving you bandwidth and speeding up the CDN requests.

Here's how you that can be done with Express 4 for static files:

// Allow access to site folder
app.use( express.static('./site', { etag: false } ) );
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.