JDK-8337684 : [17/11u] Revert JDK-8163921 backport
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 11.0.24,17.0.12
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2024-08-01
  • Updated: 2025-01-27
  • Resolved: 2025-01-06
Related Reports
Duplicate :  
JDK-8339470 - [17u] More defensive fix for 8163921
Relates :  
JDK-8163921 - HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC
Relates :  
JDK-8339470 - [17u] More defensive fix for 8163921
Description
JDK-8163921 changed the default Accept header in HTTP client. This looked to be an innocious change on a surface, but it apparently breaks applications. We are seeing internal reports where services started to receive differently-typed responses, now that we do not prefer `text/html, image/gif, image/jpeg` anymore.

Arguably, changing the Accept header to `*/*` is a good move, since it drops a preference JDK's HTTP client should not really have. But the breakages show this should only be done in major releases, so users can catch the bugs and set their Accept headers properly. We should not be doing this policy change in an update release.
Comments
Yes. I resolved this one as duplicate of JDK-8339470.
06-01-2025
can we close this out as a duplicate of JDK-8339470 ? [~shade]
06-01-2025
[17u fix-no] We decided to go for JDK-8339470 instead.
11-09-2024
[jdk17u-fix-request] Approval Request from Aleksey Shipilëv Cleanly reverts JDK-8163921. See the comments in the issue for more discussion and rationale. jdk_net tests pass. This reverts us to a known good point before JDK-8163921, so the risk should be on lower side.
19-08-2024
> Do you have a sample of an application that breaks, along with a detailed analysis of why? All our broken customer applications are internal (so far), so please excuse my handwaving: The failure mode is roughly this. We have a remote "serialization" server that can reply either formatted string (nominally, text/html) or a binary blob from the HTTP endpoint, depending on what the client wants. The "serialization" clients make requests and try to de-serialize the responses. These clients -- arguably due to overly relying on defaults -- did not set Accept headers, but expected text as the response. So, before this change, server looked at default Accept headers and compiled to the client preference, replied text, and clients "worked" by accident. After the change, server reacted to newly default Accept headers, seen no preference from the client, took its own preference, and started replying binary blobs. Which, of course, broke the clients. We got a bit lucky that a header for those blobs did not look like a correct UTF-8, and the clients failed fast and with sensible error messages. Somewhere else the problem might be still uncaught. Of course, services need to fix their client code as well: if you wanted text, you should have asked for it explicitly. Sometimes that code is buried in libraries, which necessitates dependency bump. Yes, services would have caught and remedied this problem during a major-version JDK update, as part of regular update-time overhaul of code/dependencies that are compatible with the new target JDK. For same-version JDK some (most?) services expect better compatibility, which allows JDK upgrades without bumping the dependencies and/or adapting the code. Sometimes services cannot upgrade the dependencies without significant work, so policy change in a same-version JDK update leaves them without an easy recovery path. That's why we rolled back :)
19-08-2024
OK. I agree this makes sense. I guess it makes upgrades to newer JDKs risky as well. Do you have a sample of an application that breaks, along with a detailed analysis of why?
19-08-2024
(Added JDK Updates maintainers to watch list). We have rolled this backport back in our internal releases to unbreak customers. We can technically solve the original RFC compliance issue without introducing policy change. I.e. by changing to "text/html, image/gif, image/jpeg, */*; q=0.2". But, I propose we revert the backport completely from 17u and 11u, since that gives us a rollback to known good state. Even if that state is not de jure RFC compliant. Trying to reinstate the old MIME type preference while still trying to comply with RFC might have another unforeseen consequences that I don't really want.
13-08-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u-dev/pull/2775 Date: 2024-08-02 09:02:00 +0000
02-08-2024