On Tue, 24 Mar 2026 09:17:24 GMT, EunHyunsu <[email protected]> wrote:
>> When `expiryDate2DeltaSeconds()` fails to parse the Expires attribute
>> against all date formats, it returns 0. The caller in
>> `assignMaxAgeAttribute()` then sets `maxAge=0`, which causes `hasExpired()`
>> to return true. Per RFC 6265 section 5.2.1, an unparseable Expires value
>> should be ignored, leaving `maxAge=-1` (session cookie).
>>
>> This fix introduces a sentinel constant (`Long.MIN_VALUE`) as the return
>> value for parse failure, since 0 is a valid delta for dates that match the
>> creation time. The caller checks for this sentinel and skips the maxAge
>> assignment when parsing fails.
>>
>> A new test in `MaxAgeExpires` verifies that unparseable Expires values are
>> correctly ignored.
>
> EunHyunsu has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8380549: Update B6791927.java copyright header
test/jdk/java/net/HttpCookie/whitebox/java.base/java/net/MaxAgeExpires.java
line 143:
> 141: { "GARBAGE" },
> 142: { "2024-01-01T00:00:00Z" }, // ISO 8601, not a cookie
> date
> 143: { "January 1, 2099 00:00:00 GMT" } // missing day-of-week
> prefix
Hello @ehs208, I can't find anywhere in the RFC which says January is allowed
as the name of the month https://www.rfc-editor.org/rfc/rfc6265#section-5.1.1.
As far as I can see, it only allows months to be of the form "jan". So although
this is indeed an unparseable date, the comment that says "missing day-of-week"
may not be the sole reason why this is unparseable.
Similar comment for the ISO 8601 reference in the previous line. I can't find
any reference to that in the RFC-6265. So although the date is unparseable, it
might be better to change that comment to "format not supported by RFC-6265".
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30341#discussion_r2981560285
