[
https://issues.apache.org/jira/browse/HTTPCLIENT-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17913783#comment-17913783
]
Stephane Bailliez edited comment on HTTPCLIENT-2344 at 1/16/25 3:50 PM:
------------------------------------------------------------------------
FYI this default actually breaks AWS ALBs as well. We just got hit by hit after
dependencies upgrade.
On load balancers with http listeners, sending "Upgrade: TLS/1.2" headers makes
the load balancer return a 400. Took us by surprise and took a few hours to
identify the issue.
I would tend to agree with [~bplotnick] that this is a non ideal situation.
While I do support implementing the specs, the fact a lot of proxies are broken
will have the reverse effect that will likely means software using httpclient 5
to ship with setting `protocolUpgradeEnabled` to false.
Example with curl passing "Upgrade: TLS/1.2"
{noformat}
curl -vvvv
http://test-lb-1458593638.us-east-1.elb.amazonaws.com:9070/admin/ping -H
"Upgrade: TLS/1.2" -k
Host test-lb-1458593638.us-east-1.elb.amazonaws.com:9070 was resolved. IPv6:
(none) IPv4: 10.30.100.62, 10.30.102.85 Trying 10.30.100.62:9070... Connected
to test-lb-1458593638.us-east-1.elb.amazonaws.com (10.30.100.62) port 9070
> GET /admin/ping HTTP/1.1
> Host: test-lb-1458593638.us-east-1.elb.amazonaws.com:9070
> User-Agent: curl/8.5.0
> Accept: /
> Upgrade: TLS/1.2
>
< HTTP/1.1 400 Bad Request
< Date: Thu, 16 Jan 2025 15:37:20 GMT
< Content-Type: text/html;charset=iso-8859-1
< Content-Length: 54
< Connection: keep-alive
< Connection #0 to host test-lb-1458593638.us-east-1.elb.amazonaws.com left
intact
{noformat}
While without it
{noformat}
curl -vvvv
http://test-lb-1458593638.us-east-1.elb.amazonaws.com:9070/admin/ping -k
Host test-lb-1458593638.us-east-1.elb.amazonaws.com:9070 was resolved. IPv6:
(none) IPv4: 10.30.100.62, 10.30.102.85 Trying 10.30.100.62:9070... Connected
to test-lb-1458593638.us-east-1.elb.amazonaws.com (10.30.100.62) port 9070
> GET /admin/ping HTTP/1.1
> Host: test-lb-1458593638.us-east-1.elb.amazonaws.com:9070
> User-Agent: curl/8.5.0
> Accept: /
>
< HTTP/1.1 200 OK
< Date: Thu, 16 Jan 2025 15:46:50 GMT
< Content-Type: text/plain;charset=iso-8859-1
< Content-Length: 5
< Connection: keep-alive
< Cache-Control: must-revalidate,no-cache,no-store
< Vary: Accept-Encoding
<
pong
{noformat}
was (Author: sbailliez):
FYI this default actually breaks AWS ALBs as well. We just got hit by hit after
dependencies upgrade.
On load balancers with http listeners, sending "Upgrade: TLS/1.2" headers makes
the load balancer return a 400. Took us by surprise and took a few hours to
identify the issue.
I would tend to agree with [~bplotnick] that this is a non ideal situation.
While I do support implementing the specs, the fact a lot of proxies are broken
will have the reverse effect that will likely means software using httpclient 5
to ship with setting `protocolUpgradeEnabled` to false.
Example with curl passing "Upgrade: TLS/1.2"
```
curl -vvvv
http://test-lb-1458593638.us-east-1.elb.amazonaws.com:9070/admin/ping -H
"Upgrade: TLS/1.2" -k
* Host test-lb-1458593638.us-east-1.elb.amazonaws.com:9070 was resolved.
* IPv6: (none)
* IPv4: 10.30.100.62, 10.30.102.85
* Trying 10.30.100.62:9070...
* Connected to test-lb-1458593638.us-east-1.elb.amazonaws.com (10.30.100.62)
port 9070
> GET /admin/ping HTTP/1.1
> Host: test-lb-1458593638.us-east-1.elb.amazonaws.com:9070
> User-Agent: curl/8.5.0
> Accept: */*
> Upgrade: TLS/1.2
>
< HTTP/1.1 400 Bad Request
< Date: Thu, 16 Jan 2025 15:37:20 GMT
< Content-Type: text/html;charset=iso-8859-1
< Content-Length: 54
< Connection: keep-alive
<
* Connection #0 to host test-lb-1458593638.us-east-1.elb.amazonaws.com left
intact
While without it
```
curl -vvvv
http://test-lb-1458593638.us-east-1.elb.amazonaws.com:9070/admin/ping -k
* Host test-lb-1458593638.us-east-1.elb.amazonaws.com:9070 was resolved.
* IPv6: (none)
* IPv4: 10.30.100.62, 10.30.102.85
* Trying 10.30.100.62:9070...
* Connected to test-lb-1458593638.us-east-1.elb.amazonaws.com (10.30.100.62)
port 9070
> GET /admin/ping HTTP/1.1
> Host: test-lb-1458593638.us-east-1.elb.amazonaws.com:9070
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 16 Jan 2025 15:46:50 GMT
< Content-Type: text/plain;charset=iso-8859-1
< Content-Length: 5
< Connection: keep-alive
< Cache-Control: must-revalidate,no-cache,no-store
< Vary: Accept-Encoding
<
pong
```
> 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]
