On Fri, 2023-02-03 at 15:53 -0500, Brent Putman wrote:
> Hi,
>
> I'm working on porting our project from 4.5.x to 5.2.x. This is the
> classic client. We have an HttpRequestInterceptor that does basically
> this:
>
> public void process(final HttpRequest request, ... ) {
> if (HttpVersion.HTTP_1_1.equals(request.getVersion())) {
> // add a header
> }
> }
>
> In 4.5.x the getVersion() always returned a value. In 5.2 it's
> returning null and so the interceptor doesn't work properly.
>
> Is this a bug, or the expected result due to an intentional change in
> 5.x?
>
> If intentional, then are we expected to populate the expected or
> intended HTTP version on the request before calling the client
> execute(...) method?
This is intentional. It is the responsibility of the caller to populate
that attribute. If the caller does not set the preferred protocol
version of outgoing messages it remains null.
Please note one should use HttpContext#getProtocolVersion to find out
the exact protocol version negotiated for the current message exchange.
> And setting that to say 1.0 vs 1.1 actually
> causes that protocol version to be used?
It depends on the actual protocol version negotiated during the
connection initialization. HTTP/1.1 connections can transmit HTTP/1.0
conformant messages, HTTP/2 connections cannot.
Hope this helps
Oleg
> I see that the Javadocs for
> HttpMessage (where setVersion(...)) is located say:
>
> "For outgoing messages it represents a hint what protocol version
> should be used to transmit the message."
>
> But just trying to clarify who or what is responsible for setting or
> defaulting in this request property.
>
> Thanks,
> Brent
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
