Lots of sites especially have broken www -> root domain redirects, and http -> https redirects. Often these redirects aren’t covered by your CI tests either.<p>The article is good for one-off debugging (curl is my personal favorite). For continuous monitoring, we at Heii On-Call just last week released website monitoring to assert an HTTP response status code plus Location header [1], and have some best practices for redirect monitoring for anyone with a website which will be published next week.<p>FYI these features were requested by a user who signed up from HN a few weeks ago and wanted to monitor these redirects in addition to their homepage. Hope that helps.<p>[1] <a href="https://heiioncall.com/blog/your-probes-your-rules-expected-http-status-codes-and-location-headers" rel="nofollow">https://heiioncall.com/blog/your-probes-your-rules-expected-...</a>
I can recommend writing a short script to test redirects and cache control are configured as expected for your site - here's mine (health warning: shell script) <a href="https://github.com/muxup/muxup-site/blob/main/utils/server_test.sh">https://github.com/muxup/muxup-site/blob/main/utils/server_t...</a>
Chrome has a much nicer redirect url checker - the link tools included in this article doesn't always work.<p>If you can use chrome, then use this one, best I have found in my travels - <a href="https://chrome.google.com/webstore/detail/redirect-path/" rel="nofollow">https://chrome.google.com/webstore/detail/redirect-path/</a><p>Other than that, I found this article really interesting - has gotten me into now exploring curl (especially after setting my pi 4 up as a mullvad vpn gateway with nextdns for my home network)
Client side redirects aren't the only reason why Dev Tools sometimes drop stuff.<p>I quite often try to debug a 201 and the body is not retained in the Dev Tools, even with 'Preserve logs' turned on.
I wish Firefox was as good as Chrome at correlating page visits and network requests.<p>It particularly annoys me if you reload a page with a websocket open you see the logs for the websocket closing right at the start of the subsequent load. (Preserve logs is off of course)<p>There are multiple decades old bugzilla discussions about Firefox's idiosyncratic websocket lifecycle handling. Not sure exactly which causes this, doesn't seem to be much point in debugging further
On the server side, punch into your web framework's redirect function a log with a stack trace in lower environments. That way, any time you send a redirect, you know which code was responsible, and there's no guess work involved.<p>This is especially useful in the funnest kind of cases where you have mutual recursion or other types of loops.