You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "dxbjavid (via GitHub)" <gi...@apache.org> on 2026/07/13 18:11:05 UTC
[PR] compare scheme in redirect same-authority check [httpcomponents-client]
dxbjavid opened a new pull request, #848:
URL: https://github.com/apache/httpcomponents-client/pull/848
DefaultRedirectStrategy decides whether to keep the Authorization and Cookie headers on a redirect by comparing the current and new targets, but isSameAuthority only looks at the host name and the resolved port and leaves the scheme out. A response that redirects from https to http on the same host and the same explicit port, say https://host:8443/ to http://host:8443/, is treated as the same origin, so those credentials are retained and end up being sent in the clear. I've added the scheme to that comparison so a cross-scheme downgrade counts as a different origin and the sensitive headers are stripped as they already are for a different host or port.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [PR] compare scheme in redirect same-authority check [httpcomponents-client]
Posted by "arturobernalg (via GitHub)" <gi...@apache.org>.
arturobernalg commented on code in PR #848:
URL: https://github.com/apache/httpcomponents-client/pull/848#discussion_r3573506111
##########
httpclient5/src/main/java/org/apache/hc/client5/http/impl/DefaultRedirectStrategy.java:
##########
@@ -111,6 +111,9 @@ private boolean isSameAuthority(final HttpHost h1, final HttpHost h2) {
if (h1 == null || h2 == null) {
return false;
}
+ if (!h1.getSchemeName().equalsIgnoreCase(h2.getSchemeName())) {
Review Comment:
A scheme change makes the origins different, but does not by itself require rejecting the redirect.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [PR] compare scheme in redirect same-authority check [httpcomponents-client]
Posted by "dxbjavid (via GitHub)" <gi...@apache.org>.
dxbjavid commented on code in PR #848:
URL: https://github.com/apache/httpcomponents-client/pull/848#discussion_r3593069457
##########
httpclient5/src/main/java/org/apache/hc/client5/http/impl/DefaultRedirectStrategy.java:
##########
@@ -111,6 +111,9 @@ private boolean isSameAuthority(final HttpHost h1, final HttpHost h2) {
if (h1 == null || h2 == null) {
return false;
}
+ if (!h1.getSchemeName().equalsIgnoreCase(h2.getSchemeName())) {
Review Comment:
in practice you're right that a port is normally bound to a single listener, so the same host and port serving both schemes at once is unusual. the concern isn't that the server offers both though, it's that the redirect names the next hop as cleartext: on https://host:8443 to http://host:8443 the client opens a plaintext connection and writes the authorization and cookie headers before any tls, so credentials tied to the secure origin go out in the clear. host and port alone can't tell us that, the scheme can. that's also the rationale for the origin framing (scheme, host, port per rfc 6454) rather than authority, since forwarding those headers is really an origin decision. it doesn't reject the redirect, only strips the sensitive headers, the same as a differing host or port already does.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [PR] compare scheme in redirect same-authority check [httpcomponents-client]
Posted by "ok2c (via GitHub)" <gi...@apache.org>.
ok2c commented on code in PR #848:
URL: https://github.com/apache/httpcomponents-client/pull/848#discussion_r3587077255
##########
httpclient5/src/main/java/org/apache/hc/client5/http/impl/DefaultRedirectStrategy.java:
##########
@@ -111,6 +111,9 @@ private boolean isSameAuthority(final HttpHost h1, final HttpHost h2) {
if (h1 == null || h2 == null) {
return false;
}
+ if (!h1.getSchemeName().equalsIgnoreCase(h2.getSchemeName())) {
Review Comment:
@dxbjavid Why should scheme even matter, given the strategy takes the port into account? Can there realistically be multiple protocol schemes on the same port?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [PR] compare scheme in redirect same-authority check [httpcomponents-client]
Posted by "ok2c (via GitHub)" <gi...@apache.org>.
ok2c commented on PR #848:
URL: https://github.com/apache/httpcomponents-client/pull/848#issuecomment-4989370747
@dxbjavid I am now even more confused. The strategy does not strip any headers. The comment to that effect was wrong. It merely decides if it OK to proceed with the redirect. It does so, only if the request with sensitive headers has already been sent to the origin server and got redirected to the same _very_ authority that has already seen it with all the headers and what not. I do not understand how the proposed change makes anything safer or better. I do not mind merging your change-set. I just do not understand the rationale.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [PR] compare scheme in redirect same-authority check [httpcomponents-client]
Posted by "ok2c (via GitHub)" <gi...@apache.org>.
ok2c merged PR #848:
URL: https://github.com/apache/httpcomponents-client/pull/848
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [PR] compare scheme in redirect same-authority check [httpcomponents-client]
Posted by "dxbjavid (via GitHub)" <gi...@apache.org>.
dxbjavid commented on code in PR #848:
URL: https://github.com/apache/httpcomponents-client/pull/848#discussion_r3576021015
##########
httpclient5/src/main/java/org/apache/hc/client5/http/impl/DefaultRedirectStrategy.java:
##########
@@ -111,6 +111,9 @@ private boolean isSameAuthority(final HttpHost h1, final HttpHost h2) {
if (h1 == null || h2 == null) {
return false;
}
+ if (!h1.getSchemeName().equalsIgnoreCase(h2.getSchemeName())) {
Review Comment:
agreed, and that's the intent here. the scheme mismatch only marks the origins as different, it doesn't reject the redirect on its own. an https to http hop still goes through unless there's an authorization or cookie header to protect, exactly as it already behaves for a differing host or port. the last assertion in the added test covers the plain https to http redirect staying allowed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [PR] compare scheme in redirect same-authority check [httpcomponents-client]
Posted by "arturobernalg (via GitHub)" <gi...@apache.org>.
arturobernalg commented on code in PR #848:
URL: https://github.com/apache/httpcomponents-client/pull/848#discussion_r3579536882
##########
httpclient5/src/main/java/org/apache/hc/client5/http/impl/DefaultRedirectStrategy.java:
##########
@@ -111,6 +111,9 @@ private boolean isSameAuthority(final HttpHost h1, final HttpHost h2) {
if (h1 == null || h2 == null) {
return false;
}
+ if (!h1.getSchemeName().equalsIgnoreCase(h2.getSchemeName())) {
Review Comment:
Fair enough. Still, this changes the boundary from authority to origin and extends the existing rejection policy to scheme changes. That needs a clear rationale, and the method should be renamed to isSameOrigin.
##########
httpclient5/src/main/java/org/apache/hc/client5/http/impl/DefaultRedirectStrategy.java:
##########
@@ -111,6 +111,9 @@ private boolean isSameAuthority(final HttpHost h1, final HttpHost h2) {
if (h1 == null || h2 == null) {
return false;
}
+ if (!h1.getSchemeName().equalsIgnoreCase(h2.getSchemeName())) {
Review Comment:
Fair enough. Still, this changes the boundary from authority to origin and extends the existing rejection policy to scheme changes. That needs a clear rationale, and the method should be renamed to `isSameOrigin`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [PR] compare scheme in redirect same-authority check [httpcomponents-client]
Posted by "arturobernalg (via GitHub)" <gi...@apache.org>.
arturobernalg commented on code in PR #848:
URL: https://github.com/apache/httpcomponents-client/pull/848#discussion_r3579536882
##########
httpclient5/src/main/java/org/apache/hc/client5/http/impl/DefaultRedirectStrategy.java:
##########
@@ -111,6 +111,9 @@ private boolean isSameAuthority(final HttpHost h1, final HttpHost h2) {
if (h1 == null || h2 == null) {
return false;
}
+ if (!h1.getSchemeName().equalsIgnoreCase(h2.getSchemeName())) {
Review Comment:
Fair enough. Still, this changes the boundary from authority to origin and extends the existing rejection policy to scheme changes. That needs a clear rationale
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [PR] compare scheme in redirect same-authority check [httpcomponents-client]
Posted by "dxbjavid (via GitHub)" <gi...@apache.org>.
dxbjavid commented on PR #848:
URL: https://github.com/apache/httpcomponents-client/pull/848#issuecomment-4989753717
You're right, and sorry for muddying it: nothing gets stripped, the strategy just declines to follow the redirect when the target differs and the request carries sensitive headers. My diff had also reintroduced the old comment wording, so I've rebased on master and kept your corrected phrasing.
The rationale is about the wire rather than the server. The origin server has indeed already seen those headers, but it saw them under TLS. If the Location downgrades to http on the same host and port, the redirected request is a copy of the original, so Authorization and Cookie get written to a plaintext connection where any on-path observer can read them. Host and port identify the endpoint but say nothing about whether the transport is encrypted, which is what the scheme check adds. It's the same class of issue as curl's CVE-2022-27774, where credentials followed a redirect to the same host on a different protocol.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [PR] compare scheme in redirect same-authority check [httpcomponents-client]
Posted by "ok2c (via GitHub)" <gi...@apache.org>.
ok2c commented on PR #848:
URL: https://github.com/apache/httpcomponents-client/pull/848#issuecomment-4989978375
Cherry-picked to `5.6.x`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org