Hi,
On which version of the JDK did you observe this behavior?
The behaviour of HttpCookie.parse has been updated in JDK 26,
so I would expect this to be fixed in JDK 26.
See: https://bugs.openjdk.org/browse/JDK-8359343
Could you try to reproduce the issue on JDK 26?
https://jdk.java.net/26/
If the behavior still persists, then yes it's probably a bug
since the specification for getMaxAge() now says:
```
+ * The value of this attribute is determined by the following
steps, in line
+ * with RFC 6265:
+ *
+ * <ol><li>If {@link #setMaxAge(long)} was called, return the value
set.</li>
+ * <li>If previous step failed, and a {@code Max-Age} attribute was
parsed
+ * then return that value.</li>
+ * <li>If previous step failed, and an {@code Expires} attribute
was parsed
+ * then the maxAge calculated at parsing time from that date, is
returned</li>
+ * <li>If previous step failed, then return {@code -1}.</li></ol>
```
best regards,
-- daniel
On 02/03/2026 13:35, Hyunsu Eun wrote:
Hi,
It seems that java.net.HttpCookie treats cookies with an
unparseable Expires attribute as immediately expired.
According to RFC 6265 (section 5.2.1), if the Expires value
fails to parse as a cookie date, the attribute should be ignored.
In that case, the cookie should remain a session cookie rather
than being treated as expired.
From reading the implementation, this appears to stem from
HttpCookie.expiryDate2DeltaSeconds() returning 0 when parsing
fails, after which maxAge is set to 0.
Would this be considered a bug?
I can provide a small reproducer if helpful, and would be
happy to file a JBS issue and prepare a patch if appropriate.
Thanks,
Hyunsu Eun
