JDK-8351983 : HttpCookie Parser Incorrectly Handles Cookies with Expires Attribute
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 8,11,17,21,23,24,25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2025-03-11
  • Updated: 2025-07-03
  • Resolved: 2025-06-24
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 26
26 b04Fixed
Related Reports
CSR :  
Relates :  
Sub Tasks
JDK-8360027 :  
Description
A DESCRIPTION OF THE PROBLEM :
The HttpCookie.parse() method incorrectly forces any cookie containing an "expires" attribute to be parsed using Netscape cookie rules (version 0), even when the cookie explicitly contains "max-age" attribute as specified in RFC 2109/2965.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
HttpCookie.parse("Set-Cookie: name=value; expires=Thu, 01 Jan 2026 00:00:00 GMT; max-age=360000");

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
max-age = 360000
ACTUAL -
max-age overrided by expires


Comments
Changeset: 116b8543 Branch: master Author: Michael McMahon <michaelm@openjdk.org> Date: 2025-06-24 09:15:58 +0000 URL: https://git.openjdk.org/jdk/commit/116b8543b04bfcf542af0ba03ac547a744600b7c
24-06-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/25636 Date: 2025-06-04 11:12:02 +0000
04-06-2025

The consensus seems to be that max-age should override expires. Aiming to fix this for 26.
03-06-2025

The reporter got the RFC history wrong, but the idea to make "max-age" override "expires" has some merit. Most of the time "expires" and "max-age" attributes should agree, so this is not a must have. The first RFC to discuss the possibility of Expires and max-age appearing in the same header is RFC 6265. The original cookie spec from Netscape (mentioned in the "Historical" section of RFC 2109) specified the Expires attribute, but not the max-age. The later version in RFC 2109 defined the max-age attribute, did not define expires, and instructed the clients to determine the cookie version based on the "Version" attribute. If the attribute was absent, the cookie was implicitly a Netscape cookie. RFC 2965 did not require the Version attribute, but instead tried to standardize a new Set-Cookie2 header. That header did not define Expires, so max-age was the only option. RFC 6265 removed the Version attribute, removed the Set-Cookie2 header, defined the Expires attribute, and instructed the clients to favor max-age over expires when both are set. Also, in RFC 6265, a single Set-Cookie header can only be used to set a single cookie (it was possible to set multiple cookies with a single header in RFC 2109 and 2965).
18-03-2025

Observations on macOs 15.3.1: - JDK 8, 11, 17, 21, 23, 24, 25 : Failed, observed max age different from 360000 NOTES: - When max-age is specified before expires in the cookie header, it passes - In all tests the version is equal to 0 - Setting the version manually with setVersion(1) after cookie parse, and using Version=1 in cookie header before parse, does not change the behavior and still fails
13-03-2025