304s at Fastly

Comments

3 comments

  • Steve

    Neat! I didn't know this. This means that if you're doing some tricks in vcl_fetch to explicitly set (or override) beresp.ttl, those tricks won't happen on a 304 from origin. 

  • Alexandre Marlot

    Hello,

    Thanks for sharing ! It's a very interesting case indeed ! I never got but I am now aware of it :)

    I have two questions :

    1. Why at the end Fastly return a 200 and not 304 ? (If the browser request with an Etag it should return a 304 no ?)

    2. I have never read anything about that TTL of 120s for 304 not modified (when Fastly contact the backend with If-Modified-Since or If-None-Match header), is it documented somewhere ?

    If i am understanding well, if the TTL of an object is 1 day, after that day if the backend return a 304 without cache control, you will increase the TTL of that object for 2 minutes (meaning we will have a a request to the backend every 2 minutes (only a 304). Is it correct ?

    Thanks,

    Alex

  • Squee

    Hi Alexandre,

    Excellent questions.

    1. Why at the end Fastly return a 200 and not 304 ? (If the browser request with an Etag it should return a 304 no ?)

    So, there are several different places where a 304 could occur:

    • Between the browser and Fastly
    • Between the edge POP and the shield POP 
    • Between Fastly and your origin server

    This article was directed at addressing what happens with a 304 response from your origin to Fastly and how that can impact cached objects on our servers.

    That said, you are absolutely correct. If Fastly receives a request with a If-Modified-Since or If-None-Match header, and we can respond with a simple 304, we absolutely will. But, if a request comes in from a browser that does not yet have the object cached and the object Fastly has in cache is expired, we will send the request to your origin with a If-Modified-Since or If-None-Match header. If the response from origin is a 304, we'll respond to the client request with 200.

    2. I have never read anything about that TTL of 120s for 304 not modified (when Fastly contact the backend with If-Modified-Since or If-None-Match header), is it documented somewhere ?

    ...

    So... Ummm... This was something I misunderstood. I have since corrected the article above. 

    If there’s no cache-control header on a 304, it will just refresh the object’s existing TTL accordingly. Otherwise, we will use the cache-control header on the 304 to set the objects new TTL.

    My apologies for any confusion. Thanks for asking questions that helped me correct the statement!

Please sign in to leave a comment.