JDK-8163921 : HttpURLConnection default Accept header is malformed according to HTTP/1.1 RFC
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 8,9
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2016-08-10
  • Updated: 2024-09-03
  • Resolved: 2022-01-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 17 JDK 19
11.0.24-oracleFixed 17.0.12-oracleFixed 19 b07Fixed
Related Reports
Duplicate :  
JDK-8177439 - HttpUrlConnection sends illegal "Accept" header field
Relates :  
JDK-8339470 - [17u] More defensive fix for 8163921
Relates :  
JDK-8337684 - [17/11u] Revert JDK-8163921 backport
Description
FULL PRODUCT VERSION :


A DESCRIPTION OF THE PROBLEM :
RFC 7231 [0] describes the format of the HTTP/1.1 Accept header as follows:

     Accept = #( media-range [ accept-params ] )

     media-range    = ( "*/*"
                      / ( type "/" "*" )
                      / ( type "/" subtype )
                      ) *( OWS ";" OWS parameter )
     accept-params  = weight *( accept-ext )
     accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]

HttpURLConnection sets the following Accept header in requests if it is not set [1]:

static final String acceptString =
        "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2";

The '*; q=.2' portion seems to be invalid according to the RFC spec above. 

Some http endpoints that encounter this header will reject the request and return 406 or 500. For examples see: [2] and [3].

[0]: https://tools.ietf.org/html/rfc7231#section-5.3.2
[1]: https://github.com/openjdk-mirror/jdk/blob/jdk8u/jdk8u/master/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L256
[2]: https://issues.apache.org/jira/browse/SLING-3175
[3]: https://issues.apache.org/jira/browse/OLINGO-998


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
It is possible for clients to set the Accept header via the HttpURLConnection.setRequestProperty API.
Comments
[~goetz] the only report I'm aware of is Aleksey's report above. Many servers simply ignore the accept header, and so are not affected by this change. I originally proposed a change that would keep the original intent but fix the RFC compliance, see https://github.com/openjdk/jdk/pull/7181/commits/be017d19303b3f0989c7ae92ceda5c90ea4583ba. That commit might be a better option if fixing this issue in older releases is desirable.
02-09-2024
Hi [~coffeys], [~djelinski] , A regression has been reported against this change, see JDK-8337684. Have you seen this problem somewhere in your installations?
02-09-2024
We rolled back this backport in our downstream 11u and 17u releases, see JDK-8337684.
13-08-2024
This change apparently changes the long-standing behavior what HTTP client prefers as response. We have seen production problems with this after the 17.0.12 and 11.0.24 upgrades due to this, when client code suddenly started to see different responses being returned. I would have thought just removing "*; q=.2" would have fixed the RFC compliance issue without the behavioral change. I think this change in behavior deserves at least a release note, and maybe a retroactive CSR.
24-07-2024
[jdk11u-fix-request] Approval Request from Amos "Backporting for parity with 11.0.24-oracle. Clean backport. SAP nightlies passed on 2024-04-16,17,19,20”
22-04-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2645 Date: 2024-04-11 02:42:18 +0000
11-04-2024
Fix request [17u] I backport this for parity with 17.0.12-oracle. Low risk, simple fix, already in production. Clean backport. Test passes, but also without the fix SAP nightly testing passed.
29-03-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/2343 Date: 2024-03-28 11:19:41 +0000
28-03-2024
Changeset: 28796cbd Author: Daniel Jeliński <djelinski@openjdk.org> Committer: Michael McMahon <michaelm@openjdk.org> Date: 2022-01-25 11:10:51 +0000 URL: https://git.openjdk.java.net/jdk/commit/28796cbd1d15de678b80295418f5d1f9f59176a6
25-01-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/7181 Date: 2022-01-21 16:51:20 +0000
21-01-2022
To reproduce the issue , run the attached test case. Following are the results : JDK 8u121 - Fail JDK 9-ea + 161 - Fail Following is the output with JDK 9-ea : FINE: www.MessageHeader@3b0143d35'>sun.net.www.MessageHeader@3b0143d35 pairs: {GET / HTTP/1.1: null}{User-Agent: Java/9-ea}{Host: localhost:8080}{Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive}
23-03-2017