RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with Expires Attribute

Volkan Yazici vyazici at openjdk.org
Thu Jun 5 05:36:51 UTC 2025


On Wed, 4 Jun 2025 14:23:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
>> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
>> are present in a cookie, the Max-Age should take precedence.
>> 
>> Thanks
>> Michael
>
> test/jdk/java/net/HttpCookie/MaxAgeExpires.java line 67:
> 
>> 65:         new Test(-1, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),
>> 66:         new Test(1000, "Thu, 01 Jan 2024 00:00:00 GMT", 1000, false),
>> 67:         new Test(0, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),
> 
> Maybe you could add a test case with maxAge=1000 and expires = set at the current time + 500s. The expected maxAge would be 1000.
> 
> Something like:
> 
> 
> static final String NOW_PLUS_500 =
>     DateTimeFormatter.RFC_1123_DATE_TIME.format(
>         java.time.ZonedDateTime.ofInstant(Instant.now().plusSeconds(500), ZoneId.of("UTC")));
> 
> ...
> 
> 
>     new Test(1000, NOW_PLUS_500, 1000, false),
> 
> 
> Ideally we'd like to test the same with maxAge = -1, but that could be tricky since we can't know in advance the exact value that will be computed for the new `maxAge`.

Alternatively, we could create a `HttpCookie::parse` method<sup>1</sup> accepting a `long currentTimeMillis`, and precisely determine the expected value?

<sup>1</sup> This can either be private and accessed via reflection, or package-private and accessed by placing the test in the same package.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2127986120


More information about the net-dev mailing list