Fails to fall back to IPv4 when URL can't load over IPv6
Reported by
legendm...@gmail.com,
Jul 24 2016
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36 Example URL: Steps to reproduce the problem: In this particular example, CDN fails to serve content over IPv6 despite DNS returns both A and AAA >>> Connection over IPv6 failing $ wget -6 https://assets.onestore.ms/cdnfiles/onestorerolling-1607-15000/shell/v3/images/logo/microsoft.png --2016-07-24 02:19:54-- https://assets.onestore.ms/cdnfiles/onestorerolling-1607-15000/shell/v3/images/logo/microsoft.png Resolving assets.onestore.ms (assets.onestore.ms)... 2600:1404:18::17d7:fab, 2600:1404:18::17d7:fa2 Connecting to assets.onestore.ms (assets.onestore.ms)|2600:1404:18::17d7:fab|:443... connected. Unable to establish SSL connection >>> Connection over IPv4 working $ wget -4 https://assets.onestore.ms/cdnfiles/onestorerolling-1607-15000/shell/v3/images/logo/microsoft.png --2016-07-24 02:19:44-- https://assets.onestore.ms/cdnfiles/onestorerolling-1607-15000/shell/v3/images/logo/microsoft.png Resolving assets.onestore.ms (assets.onestore.ms)... 172.233.81.254 Connecting to assets.onestore.ms (assets.onestore.ms)|172.233.81.254|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 977 [image/png] Saving to: ‘microsoft.png’ microsoft.png 100%[===================>] 977 --.-KB/s in 0s 2016-07-24 02:19:44 (349 MB/s) - ‘microsoft.png’ saved [977/977] >>> Chrome not falling back to IPv4 This site can’t be reached The connection was reset. Try: Checking the connection Checking the proxy and the firewall ERR_CONNECTION_RESET What is the expected behavior? Falling back to IPv4 if content can't be retrieved over IPv6 What went wrong? Not falling back to IPv4, throwing ERR_CONNECTION_RESET instead Did this work before? N/A Chrome version: 52.0.2743.82 Channel: stable OS Version: Ubuntu 16 Flash Version: Shockwave Flash 22.0 r0 consistent repro on 52.0.2743.82 (Official Build) beta-m (64-bit) win7 x64 52.0.2743.82 (Official Build) (64-bit) Ubuntu 16.04 x64 In this case server listens on tcp/443 but sends an RST after browser sents SSL Client Hello. What is the current condition that would trigger IPv4 fallback?
,
Jul 25 2016
,
Jul 25 2016
This seems more like an SSL issue to me - should we fall back to IPv4 in the case of an SSL server that sends RSTs over IPv6. We implement Happy Eyeballs, which causes IPv4 fallback if IPv6 connections hang or are very slow, but that's pretty much in (In terms of IPv4 fallback). In this case, the IPv6 socket connects first, so we throw away our IPv4 connection attempt (If the IPv6 connection succeeded quickly enough, we won't even have a connection attempt), and pass it up to the SSL layer. The SSL layer gets the RST, so we give up. I really don't think we want to work around this sort of broken server (Or a middlebox/proxy). I'll also note that I can get this resource via "wget -6", indicating this may well by a middlebox issue, rather than an issue with the CDN, in this case. We've gone this long without supporting broken servers of this type, and the more broken stuff we support, the more broken stuff every browser in the universe has to support. I'm going to go ahead and mark this WontFix, though if the SSL or DNS teams have other opinions, feel free to re-open.
,
Aug 1 2016
I'm not super-familiar with the Happy Eyeballs code. Do we fall back to IPv4 if plain HTTP throws ERR_CONNECTION_RESET? If not, I don't think it makes sense for HTTPS to do anything different.
,
Aug 1 2016
No; the happy eyeballs code only sets up the TCP connect jobs.
,
Aug 1 2016
As Ryan said, no, we don't. We just race them, and take the results from the first to succeed or fail. |
|||
►
Sign in to add a comment |
|||
Comment 1 by brajkumar@chromium.org
, Jul 25 2016