Happy Eyeballs for https requests?
Curley-Joe opened this issue · comments
We are looking into upgrading to okhttp version 5 for its Happy Eyeballs implementation, because we are having trouble with IPv6 reliability, but I noticed that Happy Eyeballs only does the race at the TCP level, which is the OS-level. The web server doing the TLS negotiation and https responses could still be very slow. I see that the okhttp implementation will redo the TCP race if TLS fails, but has anybody looked into doing the race at the TLS or HTTP-request level instead? Would it cause too much network traffic?
It isn't a strict implementation of Happy Eyeballs at least yet. But that said Happy Eyeballs is definitely clear on only establishing one connection. https://datatracker.ietf.org/doc/html/rfc8305#section-5
The spec is quite clear that it doesn't solve this problem at TLS or HTTPS layer https://datatracker.ietf.org/doc/html/rfc8305#section-9.2
I don't think OkHttp can safely do what you are asking, but I think you could definitely do it yourself with either a custom Call.Factory or an Application Interceptor. Might be a bit hacky, but it's unlikely we will ever implement that internally. If this is useful and you'd like some advice on this approach, I'd be happy to discuss 1:1.
Thanks for the quick reply and the offer of advice. Right now I'm just trying to figure out what our options are. I'm not even sure it will be feasible for us to upgrade to okhttp version 5 because it no longer supports HttpURLConnection compatibility.
You can paste this if you wanna use the HttpURLConnection API with the latest OkHttp.
https://gist.github.com/swankjesse/dd91c0a8854e1559b00f5fc9c7bfae70
Thanks, Jesse!