Now wait a minute. > HttpClient does include `Connection: upgrade` header with `Upgrade: TLS` already and it has always been doing so since 5.4
https://github.com/apache/httpcomponents-client/blob/master/httpclient5/src/main/java/org/apache/hc/client5/http/protocol/RequestUpgrade.java#L77 So what on earth are we talking about here? Oleg > > On Mon, Jan 6, 2025 at 3:47 AM jan luehe > > <janlu...@yahoo.com.invalid> > > wrote: > > > > > Hi Oleg, > > > this is the response we have received from the Jetty folks: > > > ====BEGIN====RFC 7.8 Upgrade ( > > > https://www.rfc-editor.org/rfc/rfc9110.html#section-7.8) > > > explicitly > > > says: > > > A sender of Upgrade MUST also send an "Upgrade" connection option > > > in the > > > Connection header field (Section 7.6.1) to inform intermediaries > > > not to > > > forward this field. > > > So whilst 7.6.1 does suggest that an Upgrade header should not be > > > forwarded (even without a Connection: upgrade), a properly formed > > > upgrade > > > request must contain the Connection: upgrade header. Note also > > > that > > > all the > > > upgrade examples in RFC9110 contain the connection: upgrade > > > header. > > > As upgrade is a very powerful semantic, we believe it would be a > > > security > > > risk to accept any but a correctly formed upgrade > > > request.====END==== > > > Please let me know what you think. Thanks! > > > On Sunday, January 5, 2025 at 10:14:23 AM PST, jan luehe < > > > janlu...@yahoo.com> wrote: > > > > > > Thank you, Oleg, for your response! > > > Some of our requests have started to get rejected (following the > > > org.apache.httpcomponents.client5 upgrade) due to this validation > > > code in > > > Jetty: > > > > > > https://github.com/jetty/jetty.project/blob/jetty-10.0.24/jetty-server/src/main/java/org/eclipse/jetty/server/HttpChannelOverHttp.java#L633-L636 > > > > > > Let me check with the Jetty folks and get back to you. > > > > > > On Saturday, January 4, 2025 at 12:50:47 AM PST, Oleg > > > Kalnichevski < > > > ol...@apache.org> wrote: > > > > > > On Fri, 2025-01-03 at 21:11 +0000, jan luehe wrote: > > > > The reason I'm asking is because when we upgraded > > > > org.apache.httpcomponents.client5 from version 5.2 to 5.4.1, we > > > > ran > > > > into issues where the client request was rejected by the server > > > > due > > > > to an invalid header combination: > > > > Upgrade: TLS/1.2Connection: keep-alive > > > > This header combination is invalid because if the "Upgrade" > > > > header is > > > > present, the "Connection" header must equal to, or contain the > > > > string > > > > "Upgrade". > > > > > > The `Upgrade` header is a standard hop-by-hop header defined by > > > the > > > HTTP protocol, see RFC 9110, section 7.6.1. It does not need to > > > be > > > included in `Connection` as a connection option. The server > > > rejecting > > > requests with `Upgrade TLS` and `Connection: keep-alive` is > > > _wrong_. > > > > > > Oleg > > > > > > > > > > > > > Since we are going through RequestConfig$Builder, > > > > "protocolUpgradeEnabled" was automatically enabled, and we had > > > > to > > > > set > > > > it to "false" in order to disable it. > > > > > > > > On Friday, January 3, 2025 at 10:12:37 AM PST, jan luehe > > > > <janlu...@yahoo.com> wrote: > > > > > > > > Support for org.apache.hc.client5.http.config.RequestConfig's > > > > "protocolUpgradeEnabled" was introduced via this commit: > > > > > > > https://github.com/apache/httpcomponents-client/commit/3235f009d5673536be5c668df409ac3f83808d89 > > > > The default RequestConfig constructor sets it to "false", > > > > whereas > > > > the > > > > RequestConfig$Builder sets it to "true" by default. > > > > Same is true for RequestConfig's "contentCompressionEnabled" > > > > and > > > > "hardCancellationEnabled" fields. > > > > I believe RequestConfig$Builder should initialize these fields > > > > to > > > > "false" also. > > > > > > > > > ----------------------------------------------------------------- > > > -- > > > -- > > > To unsubscribe, e-mail: > > > httpclient-users-unsubscr...@hc.apache.org > > > For additional commands, e-mail: > > > httpclient-users-h...@hc.apache.org > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
