Otdfbt

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?

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

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 ) );

I had similar problems with the current Chrome version at this date. The Main issue we had was chrome not caching the video that were hosted on s3 and served by Cloudfront. I explain, we are using HTML5 native video player where we use the autoplay and loop features. After that the video finished playing, chrome would request the video from Cloudfront instead of fetching it from the cache in the disk.

Two things that we have noticed, this issue was not happening with Firefox. And, some website that host their videos on their VPS are not experiencing the same issue when we use Chrome.

We are believe that the problem happen when chrome is requesting the partial data to stream the video (206 status) from Cloudfront and it seems like it does not know that the video has been completely downloaded.

We could not find a solution at this point...