-
Bug
-
Resolution: Fixed
-
P2
-
24, 25
-
b03
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8362016 | 25.0.1 | Jaikiran Pai | P2 | Resolved | Fixed | b02 |
JDK-8360095 | 25 | Jaikiran Pai | P2 | Resolved | Fixed | b29 |
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);
}
- backported by
-
JDK-8360095 java.net.HttpURLConnection sends unexpected "Host" request header in some cases after JDK-8344190
-
- Resolved
-
-
JDK-8362016 java.net.HttpURLConnection sends unexpected "Host" request header in some cases after JDK-8344190
-
- Resolved
-
- 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
-
Commit(jdk25) openjdk/jdk/41928aed
-
Commit(master) openjdk/jdk/57266064
-
Review(jdk25) openjdk/jdk/25867
-
Review(master) openjdk/jdk/25844