Still cannot prevent an updown.io check from following redirects
I raised this same issue under this discussion almost two years - unfortunately it's been completely ignored: https://updown.uservoice.com/forums/177972-general/suggestions/38068798-add-the-ability-to-disable-following-redirects.
I've worked around this in the past but it's starting to cause problems again, so I'm raising it again and this time I'll expand on the specifics of the problem I'm having.
I run web services from behind Cloudflare. When you set up Cloudflare for proxying, you provide your backend DNS entries to them and enable proxying. They'll then create public facing DNS entries for you that point to Cloudflare, and proxy connections through to your backend. For this, Cloudflare automatically add public AAAA records for all your endpoints. This is usually fine and doesn’t require your backend to support IPv6 because Cloudflare will handle consuming the IPv6 connection and proxying it to the IPv4 backend.
However, when the IPv4 backend then responds with a e.g. a 302 redirect, and the target of that redirect doesn't support IPv6, updown.io reports this as a partial connectivity failure.
This is because of the curl command used, i.e. 'curl -gkvLI6 redirect.example.com'. This command will force curl to resolve 'redirect.example.com' on its AAAA record, receive the redirect (e.g. 302), and then force it to attempt to resolve the redirect target on its AAAA record. If no AAAA record exists for the redirect target (due to lack of IPv6 support) or the backend does have a AAAA record by no IPv6 listener, the curl command fails and this is reported as a partial failure in updown.io.
The only way I think that this problem could be solved by updown.io is to offer the option of preventing the curl check from following redirects, i.e. toggle the '-L' flag off. This would let me check the health of my IPv4 and IPv6 facing endpoint without having to worry about the status of the redirect target, and then check the health of the redirect target itself separately.
Daniel G
shared this idea
So this problem has now multiple fixes:
- It's possible to prevent following a redirect by specifying the HTTP status (302, 303, etc.) in the "contains" field.
- When a site has a dual stack redirection server pointing to an IPv4-only server, it'll now automatically disable dual stack monitoring.
- If for some reasons this is still an issue (for example a broken IPv6 you can't remove from DNS), I can still disable dual-stack manually as offered in the comments.
-
Perfect, I just flipped the flag on these checks and they are now considered UP.
-
Daniel G
commented
Hi Adrien,
Thanks for the detailed response and the context.
In terms of the workaround offered, I'd be interested in taking this up. I have re-added the problematic checks - if you are able to locate my account, you should see three checks which are suffering from this problem. If you could enable this hidden flag to disable the dual-stack monitoring then that would work for me for now.
Thanks.
-
Thank you for this new suggestion Daniel and for the detailed explanation (which is perfectly correct). This situation in particular (dual stack redirection to IPv4 only website) is on my radar because other people had the same problem and there's no easy workaround on your end (I have an internal task in my roadmap which I just linked to this suggestion and bumped the priority). I will try to tackle this problem without adding more configuration if possible but it may end-up with an option to disable redirections as you suggested.
In the meantime there is one workaround I can offer you (and other people with the same problem if they are reading this). I have a hidden flag to disable "dual-stack" monitoring, which basically does the same as a curl without "-6" or "-4" so it uses IPv6 if available and falls back to IPv4 otherwise. So in this case it would (like a browser) use whatever is available for each hop, namely IPv6 to CF and then IPv4 after the redirection.
If you want me to toggle this option on some of your checks please let me know which ones. We can then remove this option once I improve this case.
PS: About the previous suggestion (https://updown.uservoice.com/forums/177972-general/suggestions/38068798-add-the-ability-to-disable-following-redirects) I got very few requests for this feature so I'm keeping it open to gather interest in parallel to this one. Though I may close it earlier if I end-up adding an option to stop following redirections.