HI Jan, I believe Oleg’s interpretation stands. The RFC specifies that the Upgrade header *must* be listed in the Connection header, but it does not explicitly mandate rejecting requests that omit it. The guidance focuses on intermediary behavior, ensuring hop-by-hop headers are stripped if not properly declared. Jetty’s stricter enforcement reflects a security-conscious approach, which is understandable, but it goes beyond the minimum requirements outlined by the RFC IMO
Arturo On Mon, Jan 6, 2025 at 3:47 AM jan luehe <[email protected]> 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 < > [email protected]> 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 < > [email protected]> 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 > > <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
