On Mon, 2025-01-06 at 06:51 +0100, Arturo Bernal wrote: > 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
Hi Arturo What Jetty developers do or say is up to Jetty developers, but it is hard to argue against an explicit 'MUST' requirement in the specification. I personally find it illogical given the purpose and clear defintion` of Upgrade as a hop-by-hop header in the specification but the explicit 'MUST' is there and I have overlooked it I will need to correct in on our end 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
