GROOVY-12274: HttpBuilder: drop default headers on a redirect to anot… - #2811
Open
paulk-asert wants to merge 1 commit into
Open
GROOVY-12274: HttpBuilder: drop default headers on a redirect to anot…#2811paulk-asert wants to merge 1 commit into
paulk-asert wants to merge 1 commit into
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2811 +/- ##
==================================================
+ Coverage 70.1837% 70.1862% +0.0025%
- Complexity 35844 35845 +1
==================================================
Files 1562 1562
Lines 132528 132536 +8
Branches 24379 24381 +2
==================================================
+ Hits 93013 93022 +9
Misses 31106 31106
+ Partials 8409 8408 -1
🚀 New features to boost your workflow:
|
This comment has been minimized.
This comment has been minimized.
…her origin
With followRedirects and no confinement, redirect following was delegated to
the JDK client, which re-issued the request to the Location target carrying
the headers configured on the builder. Those headers are applied to every
request, so a token or key among them was sent to whatever origin a
redirect named.
The platform cannot be relied on for this. Measured against a cross-host
redirect, on a chain that ends at a server which records what it received:
JDK 17.0.20 JDK 21.0.6 JDK 23.0.2
(2026-07) (2025-01) (2025-01)
Authorization stripped forwarded forwarded
Cookie stripped forwarded forwarded
Proxy-Authorization stripped stripped stripped
X-Api-Key forwarded forwarded forwarded
Two things follow. Whether the well known credential headers are protected
depends on the update level of the JDK in use, which an application cannot
choose. And a header the platform does not recognise is forwarded on every
JDK, while the builder's headers may hold anything the caller put there, so
a policy naming header names would repeat the same mistake at one remove.
Follow redirects here in every case rather than only under confinement, and
drop the caller's headers for good once a hop leaves the origin the request
started from. Same-origin redirects are unaffected, as is confinement, which
already rejected a cross-origin hop outright. A chain which returns to the
original origin does not get the headers back, since by then they have been
seen by another server.
Note this drops all of the caller's headers rather than a chosen few: which
of them carry credentials is not something this class can know.
paulk-asert
force-pushed
the
groovy12274
branch
from
August 19, 2026 00:36
aa5e91c to
f92da40
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…her origin
With followRedirects and no confinement, redirect following was delegated to the JDK client, which re-issued the request to the Location target carrying the headers configured on the builder. Those headers are applied to every request, so a token or key among them was sent to whatever origin a redirect named.
The platform cannot be relied on for this. Measured against a cross-host redirect, on a chain that ends at a server which records what it received:
Authorization stripped forwarded forwarded
Cookie stripped forwarded forwarded
Proxy-Authorization stripped stripped stripped
X-Api-Key forwarded forwarded forwarded
Two things follow. Whether the well known credential headers are protected depends on the update level of the JDK in use, which an application cannot choose. And a header the platform does not recognise is forwarded on every JDK, while the builder's headers may hold anything the caller put there, so a policy naming header names would repeat the same mistake at one remove.
Follow redirects here in every case rather than only under confinement, and drop the caller's headers for good once a hop leaves the origin the request started from. Same-origin redirects are unaffected, as is confinement, which already rejected a cross-origin hop outright. A chain which returns to the original origin does not get the headers back, since by then they have been seen by another server.
Note this drops all of the caller's headers rather than a chosen few: which of them carry credentials is not something this class can know.