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
Overall, this now looks good to me. I have added a few trivial comments inline.
Have you run `tier2` test on your setup with these changes?
test/jdk/java/net/HttpCookie/whitebox/java.base/java/net/MaxAgeExpires.java
line 150:
> 148: public void testUnparseableExpires(String badDate) {
> 149: // RFC 6265 section 5.2.1: if the expires value fails to parse,
> 150: // the cookie-av should be ignored, leaving maxAge at -1
Nit - perhaps change the comment to:
// RFC 6265 section 5.2.1: if the expires value fails to parse,
// the cookie-av should be ignored.
// That results in the HttpCookie implementation to have maxAge value of -1.
I think this might be better because it clarifies that the -1 maxAge value is a
detail of the HttpCookie implementaiton in the JDK and isn't anything to do
with the RFC-6265.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/30341#issuecomment-4118330757
PR Review Comment: https://git.openjdk.org/jdk/pull/30341#discussion_r2981584836
