You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Brent Putman <pu...@georgetown.edu> on 2023/02/03 20:53:15 UTC
5.2 ClassicHttpRequest getVersion() always returns null?
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? And setting that to say 1.0 vs 1.1 actually
causes that protocol version to be used? 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
Re: 5.2 ClassicHttpRequest getVersion() always returns null?
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2023-02-03 at 23:09 -0500, Brent Putman wrote:
>
> On 2/3/23 4:37 PM, Oleg Kalnichevski wrote:
> >
> > 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.
>
>
> Ok, thanks for confirming.
>
>
> > Please note one should use HttpContext#getProtocolVersion to find
> > out
> > the exact protocol version negotiated for the current message
> > exchange.
> >
>
> Thanks even more for this hint. I think our code should probably use
> this rather than the request field because we want to evaluate
> against
> the protocol that was actual negotiated. So just to confirm, the
> context getProtocolVersion will always be populated by the time an
> HttpRequestInterceptor runs? Presumably because the connection is
> always set up and protocol negotiated before the actual request
> machinery runs?
>
Correct.
Oleg
> This has been super helpful. Thanks again.
>
> --Brent
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: 5.2 ClassicHttpRequest getVersion() always returns null?
Posted by Brent Putman <pu...@georgetown.edu>.
On 2/3/23 4:37 PM, Oleg Kalnichevski wrote:
>
> 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.
Ok, thanks for confirming.
> Please note one should use HttpContext#getProtocolVersion to find out
> the exact protocol version negotiated for the current message exchange.
>
Thanks even more for this hint. I think our code should probably use
this rather than the request field because we want to evaluate against
the protocol that was actual negotiated. So just to confirm, the
context getProtocolVersion will always be populated by the time an
HttpRequestInterceptor runs? Presumably because the connection is
always set up and protocol negotiated before the actual request
machinery runs?
This has been super helpful. Thanks again.
--Brent
Re: 5.2 ClassicHttpRequest getVersion() always returns null?
Posted by Oleg Kalnichevski <ol...@apache.org>.
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-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org