Fastly is not respecting Expires header?

Follow
Tian

Hi all,

I’ve a couple of questions regarding the Fastly caching:

  1. I’ve set the time for stale-while-revalidate to 1 hour, however, the content served by Fastly was still stale after 1 hour when I checked.
  2. I’ve also set the Expires header as below to Sun, 19 Jul 2015 14:00:00 GMT, and the Date is Mon, 20 Jul 2015 00:42:08 GMT. However, Fastly is still serving the stale content and not respecting the Expires header.

Could anyone please help? Thanks a lot in advance.

Tian

Request URL:http://www.***.com.au/***/movies
Request Method:GET
Status Code:200 OK
Response Headers
view source
Accept-Ranges:bytes
Age:4681
Cache-Control:max-age=3600, public, stale-while-revalidate=3600, stale-if-error=129600
Connection:keep-alive
Content-Encoding:gzip
Content-Length:12069
Content-Type:text/html; charset=utf-8
Date:Mon, 20 Jul 2015 00:42:08 GMT
Etag:"a69fe485f49d6c3ecbc9096a74b80a05"
Expires:Sun, 19 Jul 2015 14:00:00 GMT
Server:Apache
Status:200 OK
Vary:Accept-Encoding
Via:1.1 vegur
Via:1.1 varnish
Via:1.1 varnish
X-Cache:MISS, HIT
X-Cache-Hits:0, 2
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-Request-Id:164f003d-0744-4780-b87b-04964f94e757
X-Runtime:0.397500
X-Served-By:cache-iad2125-IAD, cache-syd1625-SYD
X-Timer:S1437352928.373283,VS0,VE0
X-Xss-Protection:1; mode=block
0

Comments

1 comment

Sort by Date Votes
  • Cassandra Dixon

    Hi Tian,

    There are a few things I see based on this output.

    1) It appears your origin is sending a Cache-Control: max-age header.

    If this is true, the Cache-Control header will take precedence over the Expires header. We honor Surrogate-Control, Cache-Control, and Expires headers from the origin in that order.

    2) Stale-While-Revalidate means that Fastly will serve the stale version while fetching the refresh object from origin after the original TTL has expired. Based on your setup you have a TTL (Cache-Control: max-age: 3600) of an hour. The stale-while-revalidate is also set for an hour. Thus if a datacenter receives a request for an object that has expired, stale exists, and it is within an hour since the original TTL, Fastly will serve stale.

    Based on the Age header it is within this range (under 7200s: Original TTL + Stale-While-Revalidate TTL) and the request to the edge node was a MISS.

    I hope this helps explain the behavior being seen.

    Best, Cassandra

    0
    Comment actions Permalink

Please sign in to leave a comment.

New post