On Thu, 26 Mar 2026 15:17:28 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. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > EunHyunsu has updated the pull request incrementally with one additional > commit since the last revision: > > 8380549: Update test comments in MaxAgeExpires.java ### Test failure analysis I've examined the failing `ExpiredCookieTest`, and my analysis matches the one from @ehs208. On `master`: - `expiryDate2DeltaSeconds()` always returns a `long` - on parse failure it returns 0 - `assignMaxAgeAttribute()` always does `cookie.maxAge = (delta > 0 ? delta : 0)` In this PR: - `parseExpires()` returns a `Calendar` or `null` - `assignMaxAgeAttribute()` only sets `maxAge` if `cal != null` - if parsing fails, `maxAge` is left untouched, so the cookie stays a session cookie In short, this PR changes the "failed expiry parse" behavior from "expire immediately" to "ignore expiry and keep as session cookie". `ExpiredCookieTest` uses following dates: cal.set(1970, 6, 9, 10, 10, 1); // 1970-07-09 Thu 10:10:01 cal.set(1969, 6, 9, 10, 10, 2); // 1969-07-09 Wed 10:10:02 cal.set(2070, 6, 9, 10, 10, 3); // 2070-07-09 Wed 10:10:03 cal.set(2069, 6, 9, 10, 10, 4); // 2069-07-09 Tue 10:10:04 Using two-digit year formatting, this is what the `Set-Cookie` contents look like: TEST1=TEST1; Path=/; Expires=Thu, 09-Jul-70 10:10:01 GMT TEST2=TEST2; Path=/; Expires=Wed, 09-Jul-69 10:10:02 GMT TEST3=TEST3; Path=/; Expires=Wed, 09-Jul-70 10:10:03 GMT TEST4=TEST4; Path=/; Expires=Tue, 09-Jul-69 10:10:04 GMT Since we use `df.set2DigitYearStart("1970-01-01 00:00:00")`, their two-digit year interpretation will be as follows: TEST1=TEST1; Path=/; Expires=Thu, 09-Jul-1970 10:10:01 GMT # Good TEST2=TEST2; Path=/; Expires=Wed, 09-Jul-2069 10:10:02 GMT # Illegal! This is a Tuesday. TEST3=TEST3; Path=/; Expires=Wed, 09-Jul-1970 10:10:03 GMT # Illegal! This is a Thursday. TEST4=TEST4; Path=/; Expires=Tue, 09-Jul-2069 10:10:04 GMT # Good Both on `master` and in this PR, - `TEST1` has expired in 1969, and is removed. - `TEST4` will expire in 1969, and is kept. Different from `master`, because of the the new "keep as session cookie on expiry date parse failure" behavior, and illegal two-digit year interpretations of `TEST2` and `TEST3`, this PR additionally keeps them as session cookies. That is, - On `master`, only `TEST4` is kept. - In this PR, `TEST2`, `TEST3`, and `TEST4` are kept. ### The new behavior & RFC As explained above, this PR changes the "failed expiry parse" behavior from "expire immediately" to "ignore expiry and keep as session cookie". [RFC 6525 > 5.2.1. The Expires Attribute] states the following: > If the attribute-value failed to parse as a cookie date, ignore the cookie-av. I also agree with @ehs208 conclusion here. The new behavior matches the RFC. I propose fixing the test instead. [RFC 6525 > 5.2.1. The Expires Attribute]: https://datatracker.ietf.org/doc/html/rfc6265?__cf_chl_f_tk=br3wM.GB.CiIIbXk_b5EyrZbfF27U3M0xTS4jhHja84-1783367766-1.0.1.1-oMv7Kd9ycyR1mDK_FfOvlkWVXDAKOYBil1lpV516Sy4#autoid-28 ------------- PR Comment: https://git.openjdk.org/jdk/pull/30341#issuecomment-4897166386
