Debug browser redirects without ruining your day | Hacker News Reader

Debug browser redirects without ruining your day

dodov.dev

47 pointscassidoo10 comments

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.

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.

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.

[1] https://heiioncall.com/blog/your-probes-your-rules-expected-...

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) https://github.com/muxup/muxup-site/blob/main/utils/server_t...

Chrome has a much nicer redirect url checker - the link tools included in this article doesn't always work.

If you can use chrome, then use this one, best I have found in my travels - https://chrome.google.com/webstore/detail/redirect-path/

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)

Did you mean this link? https://chrome.google.com/webstore/detail/redirect-path/aomi...

I think that was mentioned in the article too.

Client side redirects aren't the only reason why Dev Tools sometimes drop stuff.

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.

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)

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

the worst is meta tag refresh - not many browser tools for disabling it

If three are no built-in tools for browsers, maybe use add-on/extension to disable it in the meantime?

Hi, can't speak for any other browsers but with Firefox you can easily disable it without any tools. Just modify the setting accessibility.blockautorefresh (set it to true) in about:config and then when a page attemps to redirect you get a confirmation dialog (similar to when you block a popup) asking if you want to allow it to happen.

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.

This is especially useful in the funnest kind of cases where you have mutual recursion or other types of loops.

Reply on news.ycombinator.com