Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
5.1.2, 5.2-alpha1
-
None
Description
Currently, a user is able to add HttpRequestInterceptor when building a new client using HttpAsyncClientBuilder. However, when executing a request, these interceptors are called at point when the final application protocol has not been established yet. The protocol returned by httpcontext is always http/1.1, the protocol of the initial CONNECT request. Since the interceptors do not have access to the final protocol, then the user must commit to an application protocol pre-emptively when constructing their request in terms of header capitalization, including the Host/Connection header or not, how cookies are appended, etc. This is clearly problematic since it cannot be known pre-emptively what protocol the server on the other end will end up choosing when a connection is established.
On line 925 of HttpAsyncClientBuilder, I can see that a DefaultHttpProcessor is provided to the IOEventHandlerFactory, which contains HttpRequestInterceptors that DO have access to the final application protocol information, because they are called at a later point in time when this information has been fully established. I see that if the protocol was assumed by the user to be H2, but the final connection ends up using 1.1, then a Host and Connection header are added to the request if they are missing. However, the opposite is not provided. That is, if the protocol is assumed to be 1.1 and the Host / Connection headers are included by the user, but the connection upgrades to H2, it results in an illegal request due to invalid headers.
To solve this issue, it would be nice if a user was able to add additional interceptors to the DefaultHttpProcessor on line 925, so that they too are able to have access to protocol information and potentially augment their request where needed.