Okhttp: Support “HTTP” URIs (HTTP Upgrade mechanism)

[JanAndersson]

As far as I understand this isn't supported in OkHttp. As it is part of the HTTP/2.0 standard I beleive this would be of great value to OkHttp...

[swankjesse]

Not sure I follow. Are you asking for HTTP/2 over plaintext?

[adriancole]

I'm guessing Jan's asking for us to support initializing from text protocol, then switching to binary frames. This could be done regardless of whether the transport is plain-text or not, though the spec seems to only discuss this in context of clear-text.

Ex.

     GET / HTTP/1.1
     Host: server.example.com
     Connection: Upgrade, HTTP2-Settings
     Upgrade: h2c
     HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
...

Besides the above approach, clear-text could be supported without negotiation per the prior knowledge clause. In other words, if someone's registry knows this server responds on port X to h2c, then just send frames there without any nego.

[JanAndersson]

Yes, this is exactly what I'm asking about.

[yschimke]

I'm working with a backend that supports plaintext assumed http/2. So I'd like to look into this, ideally both

• plainttext h2c via upgrade
• assumed plaintext http/2
• support for http/2 only via ALPN - e.g. fail if the server doesn't support http/2

Specifically this could relax OkHttpClient.Builder.protocols

     * @param protocols the protocols to use, in order of preference. The list must contain {@link
     * Protocol#HTTP_1_1}. 

[swankjesse]

There's no spec for plaintext assumed HTTP/2. That's nonstandard and won't work with other tools.

[yschimke]

Isn't this section 3.4 "Starting HTTP/2 with Prior Knowledge"

http://http2.github.io/http2-spec/index.html#rfc.section.3.4

In this case prior knowledge is clients configuring the protocol list to only HTTP_2

[swankjesse]

Ah you're right. I still think it’s unwise to skip the upgrade path.

[yschimke]

Unfortunately, if the server also assumes h2c over plaintext then the initial HTTP/1.1 request with upgrade header will cause the server to barf. i.e. I'm getting this now. With Netty all three scenarios are possible.

So while I agree that it may be unwise, its documented as standard, and possible in the wild.

[yschimke]

Minus the plaintext Upgrade support which I'm still working on this turned out pretty easy to add assumed h2c mode, and http/2 only via ALPN. Do you see any reason why this couldn't land once completed with proper tests etc?

https://github.com/yschimke/okhttp/pull/1/files

[JaySWang]

Hi guys, do you have any plan to support h2c?

[swankjesse]

None currently.

[mjpitz]

I have an h2c prior knowledge solution out for review. Changes to critical code paths was rather minimal and I was able to leverage much of the existing test infrastructure. See gh-3873

[swankjesse]

We did HTTP/2 prior knowledge in 3.11. I’m not planning anything further here!