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

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
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 (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

1 Answer 1


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: 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.


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

Your Answer


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.