Redirects to signed S3 URLs are cached until Expires is hit

I’ve just stumbled over something that’s not a bug, in facts it’s working perfectly, but I would still like to know why it’s working

For certain requests to our servers, we’re redirecting to Amazon S3 with a signed URL (basically large XML files). We’ve set no-cache headers (please see below), so I would think that requests don’t get cached at all. But they do get cached (as you can see from the HIT from the origin shield and the edge server).
Now, the funny thing is: the resources are expired as soon as the signed URL expires and a fresh version of the redirect is sent to the client. That feels like magic to me (magic that works! ). My guess is that Fastly looks at the Expires HTTP GET param and uses it to fetch from the backend servers once it expired?

HTTP/1.1 302 Found X-Runtime: 0.376492 Location: https://our-bucket.s3.amazonaws.com/facebook-product-feed/feed.xml?AWSAccessKeyId=xxxxx&Signature=yyyy&Expires=1456389440 Server: nginx/1.4.6 (Ubuntu) Strict-Transport-Security: max-age=31536000 Cache-Control: no-cache, no-store, must-revalidate Status: 302 Found Fastly-Debug-Digest: 4563d3adefeae4e2d3e4becd07d6e4146f87c0075b5f3b16743f64571e2af7e1 Accept-Ranges: bytes Pragma: no-cache X-Served-By: cache-iad2151-IAD, cache-lcy1132-LCY Content-Length: 236 Via: 1.1 varnish, 1.1 varnish Vary: X-UA-Device Connection: close Date: Thu, 25 Feb 2016 08:33:02 GMT X-Rack-Cache: miss X-UA-Device: desktop X-Cache-Hits: 1, 1 Expires: 0 X-Request-Id: daf2f985eabecfc69b9b709ad77afee7 Age: 2 X-Cache: HIT, HIT Content-Type: text/html; charset=utf-8 X-UA-Compatible: IE=Edge,chrome=1

Rogier Mulhuijzen

February 26, 2016 00:23

We don't do anything with no-cache unless you configure us to do so. And yes, in the absence of max-age we do listen to Expires. Although, we do expect the value of Expires to conform to the RFC, and a value of 0 does not. So in this case, we would apply a default 120 second TTL.

Christoph

March 11, 2016 10:10

Sorry for the very late reply! Ah, that makes sense! And because the default TTL was 120sec I believed that the expiry is happening along with the refresh of the signed S3 URL.

Thanks again! :slightly_smiling:

Comments