-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Image loading fails if ipv6 is available but can't connect #797
Comments
So here's my research rundown: Sorry, but that's just how it is. I do appreciate you looking thoroughly into this however so I could give a good response. |
Can't we just disable it? Or rather add a setting to disable it. |
The default Mode.SYSTEM should attempt all addresses in order, going to the next one if it does not succeed. I'm more likely to blame a network configuration issue rather than OkHttp on this one, and I'd rather not disable IPv6 if not necessary. |
I still think we should add a setting to disable this shit along with HTTP/2 (two separate settings). If either of them helps the users who can't load images - great. If not then, well, at least we tried.
Where I live there are like two ISPs countrywide that provide IPv6 support. I bet my country is not the only one. Which means disabling ipv6 should be fine. |
I spent some time tracking down why it fails on some networks but works on others while browsers always work: if ipv6 is available but unreachable, kuroba never retries on ipv4.
Test at will by null routing i.4cdn.org ipv6 only, images will refuse to load but 'open in browser' pops up with a very short delay. If you have a router you control, add 2606:4700::6810/96 (i.4cdn.org) to a firewall blocklist.
This is 100% repeatable if you have working ipv6 to compare with.
The text was updated successfully, but these errors were encountered: