Azure / Azure/azure-sdk-for-java
Allow for setting HTTP Protocol Version w/out depending on an HTTP Client Implementation
- Dominant language
- Java
- Stars
- 2.6k
- Forks
- 2.2k
- Avg merge
- 2d 8h
- Merged PRs (30d)
- 178
Description
**Is your feature request related to a problem? Please describe.**
Near as I can tell, when using the com.azure.core.http client, you can only select between HTTP/1.1 and HTTP/2 by using one of the com.azure.core.http implementation builders (Netty, OKHttp, Vertx, Java11) and not via the interface. This is problematic because it locks integrating codebases into a single client implementation if they wish to specify which versions of the protocol are available for use.
**Describe the solution you'd like**
It would be nice if the HTTPClientOptions allowed for the choice of supported protocols. This would allow for configuration of the underlying implementation indirectly and thus allow for integrating libraries to avoid specifically indicating that the utility must depend on Netty/OKHttp/Vertx/Java 11. This makes it easy for maintainers of utilities to swap in whichever HTTP client implementation they prefer via Maven or Gradle dependency inclusions/exclusions. Additionally, downstream users of the library could also hot swap client implementations for their project, given specific project needs. For instance, I tend to write a lot of Quarkus applications and the Vert.x client is nice for GraalVM Native Image builds.
**Describe alternatives you've considered**
Alternatively, if out of the box all client implementations supported both 1.1 and 2, and would auto-negotiate then this configurability would not be needed for a majority of projects. The client could attempt HTTP2 first and if necessary downgrade connections to HTTP/1.1 when needed.
Contributor guide
Assessment
This issue has not been assessed yet.