[
https://issues.apache.org/jira/browse/HTTPCLIENT-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17914386#comment-17914386
]
Stephane Bailliez commented on HTTPCLIENT-2344:
-----------------------------------------------
Leaving some additional details about my investigation when providing details
to AWS support regarding this issue.
This might be useful for future readers / search engines as I can imagine
similar issues will happen for a very long time.
As a reminder HttpClient 5.4 emits "Upgrade: TLS/1.2" and "Connection: Upgrade"
by default on a HTTP connection.
At this time, the AWS ALB when receiving "Upgrade: TLS/1.2" with "Connection:
Upgrade" on a HTTP listener actually ends up dropping "Connection: Upgrade"
header when forwarding to the target group.
As a consequence of the AWS ALB behavior, depending on the HTTP server in the
target group, the behavior will be undefined downstream depending on how strict
the specs are implemented on the target http server.
For example:
* Jetty (10.0.24) when receiving only "Upgrade: TLS/1.2", will return with a
[400 bad request as expected by the
specs|https://github.com/jetty/jetty.project/blob/d5384207795da96fad32db8ea8d26b69955bcc03/jetty-server/src/main/java/org/eclipse/jetty/server/HttpChannelOverHttp.java#L636].
Caveat, in our case , this 400 was NOT logged in the access log and further
delayed root cause identification as it was initially believed the proxied
request did not reach the target.
* openresty 1.19.3.2 does not care about the missing "Connection: Upgrade"
header and will handle the request just fine.
> HTTP/1.1 TLS Upgrade (RFC-2817) should not be default
> -----------------------------------------------------
>
> Key: HTTPCLIENT-2344
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2344
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 5.4
> Reporter: Ben Plotnick
> Priority: Minor
>
> Version 5.4 added RFC-2817 support, which by default tries to upgrade since
> protocolUpgradeEnabled is default enabled.
> Although the strict reading of the spec would indicate that a server should
> ignore upgrade requests that it cannot service, conservative proxies might
> reject these requests entirely. This is the case in Envoy today
> I don't see a big advantage to enabling this by default and it is causing
> real issues now.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
