-
Bug
-
Resolution: Unresolved
-
P2
-
24, 25
The cleanup in JDK-8344190 to remove uses of SecurityManager APIs introduced a behaviour change.
https://github.com/openjdk/jdk/commit/6f4dfa66268c7aef0298af7f18d8e8bd4eb21656#diff-01f771140742cab503b4a5e8b39dfc1ebac25b1a99b9a8f82f5893390dc0763dL657-L659
The logic for setting the Host request header changed from
if (reqHost == null ||
(!reqHost.equalsIgnoreCase(host) && !checkSetHost()))
{
requests.set("Host", host);
}
to:
if (reqHost == null || !reqHost.equalsIgnoreCase(host)) {
requests.set("Host", host);
}
With the SecurityManager disabled, checkSetHost() returns true, so !checkSetHost() would always be false. So the behavior preserving change would have been:
if (reqHost == null) {
requests.set("Host", host);
}
https://github.com/openjdk/jdk/commit/6f4dfa66268c7aef0298af7f18d8e8bd4eb21656#diff-01f771140742cab503b4a5e8b39dfc1ebac25b1a99b9a8f82f5893390dc0763dL657-L659
The logic for setting the Host request header changed from
if (reqHost == null ||
(!reqHost.equalsIgnoreCase(host) && !checkSetHost()))
{
requests.set("Host", host);
}
to:
if (reqHost == null || !reqHost.equalsIgnoreCase(host)) {
requests.set("Host", host);
}
With the SecurityManager disabled, checkSetHost() returns true, so !checkSetHost() would always be false. So the behavior preserving change would have been:
if (reqHost == null) {
requests.set("Host", host);
}
- caused by
-
JDK-8344190 Cleanup code in sun.net.www.protocol.http and sun.net.www.protocol.https after JEP 486 integration
-
- Resolved
-
- links to
-
Review(master) openjdk/jdk/25844