I noticed some interesting behavior coming from netlify server while browsing, so figured I’d post here!
It looks like netlify is sending cache-control headers for 301 redirects from @ → www when www is selected as a primary domain.
It looks like this means if anybody tries to access https://mambu.com even after having visited before, the browser will still make a request to netlify! (Observed on Google Chrome)
If true, this results in decreased performance for subsequent requests since the request requires a DNS lookup, round trip HTTP request and response, followed by the redirect.
The expected behavior would be for the redirect to be issued without any DNS lookup / HTTP request.
If the cache-control headers are removed, I think the redirect will be issued from the browser internally. I would also think this would reduce load on netlify Thoughts?
Your observation is mostly correct: We ALWAYS have the browser check in with us to see if there is a new deploy with associated new content. It’s a bit misleading on the 301 redirect; the browser THERE caches the 301 and ignores our cache-control setting, is my understanding.
That setting though is how our service can provide truly atomic rollbacks and deploys, and how you can be sure that your visitors receive the latest content. Any timeout you set will be wrong at some point (directly after the deploy) which is why we advise you not to set different headers in our best practices doc:
You can certainly override our defaults, but if you break your site, it will be impossible to fix until the timeout you set has passed. After telling a few hundred customers that their settings had broken their site for the long term, that is our “one size fits almost everyone” advice
Thanks for the reply @fool (interesting username by the way )! I just want to clarify, I’m not referring to a manual redirect, rather one that’s set up automatically via netlify domain settings (picture below).
on the 301 redirect; the browser THERE caches the 301 and ignores our cache-control setting, is my understanding.
My observation (in chrome) has been that the browser does not cache the redirect and that the cache-control headers override the browser cache.
I believe this redirect is set up via the domain settings page:
Is it possible to override the cache-control headers for this redirect in particular? I ask because I think the omnibar in chrome and firefox might use the non-www domain when users access the site, resulting in a possible performance penalty for each access.
Interesting! I looked at this with one of my colleagues and:
I don’t believe you can override any headers for that specific “automagic” redirect.
I do see the same behavior you describe of the browser (I tested in firefox) not caching that 301 result - it’s transferred instead of remaining in cache, even when the rest of the site’s assets are.
I’ve raised this question to our edge network team about whether that is intended. I can think of a workaround (setting a different “dummy” primary custom domain, adding www + bare domain as aliases, adding your specific bare->www redirect as manual, set custom cache-control headers on that URL to allow caching) but that is pretty painful so hopefully they’ll be able to enlighten us as to whether that is a behavior we can/will change across the CDN, or if my failure to override was perhaps user error, or what . It is likely they will only see my question next week, since most of them are on holiday this week.
Thanks for bringing it up and your patience while we research!
We worked with the team and, the best way to reliably send your custom headers would be to ensure that the redirect is performed by domain aliases. You can set a dummy primary domain and force the domains as domain aliases to work around this .
Thoughts?
)! I just want to clarify, I’m not referring to a manual redirect, rather one that’s set up automatically via netlify domain settings (picture below).
. It is likely they will only see my question next week, since most of them are on holiday this week.
.