Okhttp: [HTTP/2] HTTP_1_1_REQUIRED not handled correctly

[rfc2822]

There are cases when the server resets a HTTP/2 stream with HTTP_1_1 REQUIRED. I think that okhttp should then automatically retry requests with HTTP/1.1.

For instance, when using client certificates for authentication (by setting an appropriate socket factory in OkHttpClient.Builder), HTTP/2 can't be used yet. However, okhttp tries HTTP/2 first for such requests (which is absolutely OK and intended), and then the server resets the stream with HTTP_1_1_REQUIRED, which means (RFC 7540):

The endpoint requires that HTTP/1.1 be used instead of HTTP/2.

In this case, I think that okhttp should retry with HTTP/1.1 automatically, because

• it now knows that HTTP/2 is not available for this endpoint and thus the request has not been delivered yet, and
• HTTP/1.1 will work for this endpoint, and
• there is no reason why the calling application should handle this itself instead of okhttp.

For client certificates, this situation can be worked around in the client that calls okhttp by restricting the request to HTTP/1.1, but there may be other reasons why a server doesn't allow HTTP/2 for an endpoint, and this could happen without prior knowledge on application side.

If there's anything you need or I can do to further assist in this, just let me know :)

Edit: I don't know whether this should be labelled as a "bug", but now I can't change it anymore.

[swankjesse]

Oooh, tricky one. There's interesting consequences here, such as the interaction with cleartext HTTP/2.

We should be able to fix regardless. Probably need to retry with a modified ConnectionSpec, which is something we've never needed before. This will be a decent amount of careful work to get right!

[yschimke]

@swankjesse or approach something like the https://github.com/square/okhttp/blob/032716b6a070e37b7c95ed40848cf881374553cf/okhttp/src/main/java/okhttp3/internal/connection/RouteDatabase.kt which caches the failures

[yschimke]

Won't fix, less of an issue over time.