I’m trying to set up a route that checks for a query string and if it matches, set a cookie and then redirect to the homepage (for opting into a beta version in this case). I managed to get the headers set and the redirect working, but it seems like the cookie isn’t getting sent to the server after the redirect happens because the browser doesn’t send a cookie header and instead is opts to load the request from cache. The cookie does get accepted though, so hitting refresh does send the user to the beta root, but ideally they should be taken there immediately.
Should I disable caching entirely? Is there a way to instruct the browser explicitly to send the cookie to the server on the next request, or is there a more straightforward way to set this up besides what I have below?
Maybe instead of redir you could use respond with a carefully crafted HTML payload that has a simple JS <script> tag that does document.location.href = "/"; or something to that effect. Note you might also need to set the Content-Type header to text/html so the browser handles it correctly.
EDIT: Looks like setting specific Cache-Control headers is the right way to go about this, as it will give me more fine-tuned control over what gets cached, for how long, and when validation is required.
@matt I’m using MS Edge for Mac (which is chromium-based) however Firefox is also exhibiting this behavior as well. Safari however isn’t. With both Chrome and Firefox, even though it makes sense that the browsers are caching pages but what’s odd to me is that they skip sending the Cookie header even though a new cookie was just accepted and load the page from the cache instead.
@francislavoie, the JS response does redirect the browser correctly, however Chrome, Chromium-Based and Firefox still prefer to pull the page from cache even when this method is used. I’ve been using a max-age=10 expires to test how the browsers handle the page when the cookie expires and have also seen the opposite behavior too: the browser hangs onto the page available at the alternate root until the refresh button is pressed, at which point the original root is requested.
I’m not a fan of modifying intended behavior in order to get a desired result at the expense of user experience, so disabling the cache entirely is something I’m wary of. I also tried setting a Cache-Control: must-revalidate header alongside my HSTS headers for every request that seems to force the browser to revalidate the cache on every request but at the expense of not loading the HTML response from cache anymore.
Better than leaving it up to the browser to decide whether or not it wants to send the cookie though, which could lead to some very unexpected behaviors so I want to ensure I get consistency with my final solve for this.
Wouldn’t it be easier to just make a subdomain like beta.domain.test which would serve the other version instead? Is there something preventing you from taking that approach?
Yeah, I might do that, but I just edited my original post to say that I think defining clear cache headers is the right way to go about this. Barring anything else a subdomain might be a better way to go.