Cloudfront - why is this not being "browser cached"?

Here's the curl -I response to my Javascript file:

    HTTP/1.1 200 OK
    Content-Type: text/javascript
    Content-Length: 72640
    Connection: keep-alive
    Date: Sat, 18 Feb 2017 16:12:06 GMT
    Cache-Control: 86400
    Last-Modified: Wed, 15 Feb 2017 15:09:28 GMT
    ETag: "a6ee06ff5e49a4290bb2aabe5e0f9029"
    Server: AmazonS3
    Vary: Accept-Encoding
    Age: 1173
    X-Cache: Hit from cloudfront
    Via: 1.1 3b17302562f1709d8b6c9f7be1.cloudfront.net (CloudFront)

I can see the Cache-Control tag there. Not sure what the Vary and the ETag are doing, but so be it. Does this somehow specify to a user's browser NOT to cache this file? Why are Pingdom or Goog PageSpeed not recognising this as a browser-cacheable file?

Solution

Your Cache-Control header is present, but the value is not actually valid. The correct format looks like this:

Cache-Control: max-age=86400

The number, by itself, is meaningless.

ETag: is the entity tag -- an opaque value that uniquely identifies the current content of a given URL. If the content changes, the ETag will also change. A browser with a cached copy may use this value for subsequent requests to ask that the server only return the content if it differs, by sending an If-None-Match: request header, including the last-seen ETag.

Vary: tells the browser that certain changes to the request may generate a different response. Unlike browsers, curl doesn't advertise its ability to support gzipped payload unless you specify the --compressed option. Adding that option when invoking curl triggers the addition of Accept-Encoding: gzip to the request, which may trigger the response to be compressed if you have that option enabled in CloudFront.