Main API

public interface UpgradeHandler<T> {
  T connect(OkHttpClient client);

  boolean supportsHttp11();

  boolean supportsHttp2();

  /**
   * https://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml
   */
  String connectProtocol();

  Request addUpgradeHeaders(Request upgradeRequest);

  void failConnect(Response response, IOException e) throws IOException;
}

The public API implications here are pretty devastating. Do we really need to alter the surface area so much?

I can implement it with all internal changes for now. But I’d love to be able to use with other external upgraded protocols provided by libraries. I can make that a completely separate later PR and discussion

You had me at "The public API implications"

I think it’d be great to get this working. I’m using a lot of web sockets in one of my current projects and this could make things a lot smoother.

How does the client indicate that we should attempt HTTP/2? Do we need to set policy? I think that’s the trickiest part of the whole business.

Good question. I was planning to attempt HTTP/2 once per client/host when there is existing connection. Then remember failure. Default to http/1.1 for new connections.

I think getting in the basic support first is useful. Before widespread adoption and hopefully to help foster it.

OkHttp client API isn’t really helpful for per request or per host changes.

Any suggestions? It's not public API yet - policy implies it would be.

My preference is that eventually it just works: if the server can do HTTP/2 web sockets we use ’em.

To get there I think we probably do a phased migration in:

• initially it’s off by default with some hint to turn it on (maybe a header on the Request?)
• later it’s on by default with some hint to turn it off (another header?)

In either case I think we get something like RetryAndFollowUpInterceptor to fallback to HTTP/1 if HTTP/2 doesn’t work.

No time to fix up at the moment.