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
