Skip to content
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

Loading full HTML specification occasionally waits for 2 minutes before initiating the network request #11038

Open
jdm opened this issue May 5, 2016 · 10 comments

Comments

@jdm
Copy link
Member

@jdm jdm commented May 5, 2016

Wireshark confirms the preposterous title. When I run ./mach run -r https://html.spec.whatwg.org/, I get a grey window for two minutes before any content appears. Wireshark shows no traffic between my machine and html.spec.whatwg.org before that point. I've only been able to reproduce this on my macbook so far, not my desktop linux machine.

@jdm
Copy link
Member Author

@jdm jdm commented May 6, 2016

Amazingly Instruments.app claims that it's sitting blocked inside TcpStream::connect for the entire duration of the wait.

@fduraffourg
Copy link
Contributor

@fduraffourg fduraffourg commented Jun 24, 2016

It seems to be an IPv6 issue with whatwg servers.

$ telnet html.spec.whatwg.org 443  
Trying 2607:f298:4:148::98:2ff3...
^C
zsh: interrupt  telnet html.spec.whatwg.org 443

$ host html.spec.whatwg.org
html.spec.whatwg.org has address 75.119.197.251
html.spec.whatwg.org has IPv6 address 2607:f298:4:148::98:2ff3

$ telnet 75.119.197.251 443  
Trying 75.119.197.251...
Connected to 75.119.197.251.
Escape character is '^]'.
^]
telnet> quit
Connection closed.

A network capture shows that TCP SYN packets sent over IPv6 don't get any reply. When we fallback to IPv4, the connection is properly established.

This is not a servo issue :)

@jdm
Copy link
Member Author

@jdm jdm commented Jun 24, 2016

On the other hand, other browsers do not exhibit this problem, so presumably there's some way to mitigate it.

@fduraffourg
Copy link
Contributor

@fduraffourg fduraffourg commented Jun 24, 2016

There is a preference on Firefox which is called network.http.fast-fallback-to-IPv4. With it enabled, it waits 250ms and then fallback to IPv4. When disabled, it waits much more longer.

A similar mechanism could be added to Servo. But I suppose hyper should be in charge of handling such fallback.

@jdm
Copy link
Member Author

@jdm jdm commented Jun 24, 2016

@seanmonstar What are your feelings about a non-IPv6 fallback API?

@seanmonstar
Copy link
Contributor

@seanmonstar seanmonstar commented Jun 24, 2016

@jdm That'd be really neat. It's also not something that can done in TcpStream::connect. It may be possible to do some fancy things in a custom NetworkConnector for servo...

You'd need hostname.to_socket_addrs() method to get a list of IP addresses for the given host... It would then need mio (or net2?) to do a nonblocking connect call on the addresses you want, so you can cancel them after your specified time.

@nox
Copy link
Member

@nox nox commented Oct 2, 2017

Is this still an issue, given we bumped Hyper etc?

@jdm
Copy link
Member Author

@jdm jdm commented Oct 2, 2017

Yes.

@seanmonstar
Copy link
Contributor

@seanmonstar seanmonstar commented Oct 2, 2017

@atouchet
Copy link
Contributor

@atouchet atouchet commented Nov 2, 2018

I believe this has been fixed now with the update to hyper 0.12. @jdm can you confirm?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.