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. 

    1
    Comment actions Permalink
  • 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

    0
    Comment actions Permalink
  • 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!

    0
    Comment actions Permalink

Please sign in to leave a comment.