Stale while revalidate issue... fix at fastly

[ranguard]

trafficstars

21:36 < mspo> is stale-while-revalidate safe with shielding? 21:37 <+amandasf> it's safe as long as you use the code block we mention in the docs 21:38 <+amandasf> if (req.http.Fastly-FF) { 21:38 <+amandasf> set req.max_stale_while_revalidate = 0s; 21:38 <+amandasf> } 21:38 <+amandasf> https://docs.fastly.com/guides/performance-tuning/serving-stale-content.html 21:38 < mspo> not sure I have that 21:38 < mspo> probably explains it 21:40 <+amandasf> Yeah, swr will ruin your day if that code's not in place :) 21:41 < mspo> just added it as a snippet 21:42 <+amandasf> That won't update the TTLs, so you'll need to purge again to get everything working properly (you probably already know that, but better safe than sorry) 21:43 < mattrobenolt> Speaking of this, since I was goign tobe dipping my toes into SWR. How does this interact with purges? 21:44 < mattrobenolt> If I purge a url, and it attempts to fetch, and the origin is down... can it serve stale still? 21:44 < mattrobenolt> I guess asking about a soft purge. 21:44 < mattrobenolt> If that's a thing. 21:44 < mattrobenolt> jk https://docs.fastly.com/guides/purging/soft-purges.html 21:45 < mspo> yeah it was soft purging that was causing my issue 21:45 < mspo> I didn't have the same problem with regular 21:50 < mspo> https://docs.fastly.com/guides/performance-tuning/shielding#caveats-of-shielding 21:50 < mspo> could use that 21:51 < mspo> or just like, if you enable shielding, all of these things should be automatically added or suggested :) Day changed to 13 Jun 2018 05:59 < ranguard> ahhh! that SWR + shielding explains a lot! 06:00 * ranguard adds it to his todo for today