On Wed, 4 Jun 2025 14:23:01 GMT, Daniel Fuchs <dfu...@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
