On Thu, 26 Mar 2026 22:17:27 GMT, EunHyunsu <[email protected]> wrote:
>> 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? > >> Have you run `tier2` test on your setup with these changes? > > I ran the `jdk_net` tier2 tests and `ExpiredCookieTest` failed — and after > investigation, it is related to this change. > > **Root cause:** > > `ExpiredCookieTest` generates 1969/2070 dates in `yy` format. When > `HttpCookie` re-parses them, `set2DigitYearStart(1970)` shifts the century, > causing a day-of-week mismatch that fails `setLenient(false)`. > > With the old code, parse failure returned `0` → `maxAge=0` → not stored. > With the new code, parse failure returns `null` → `maxAge=-1` → stored as a > session cookie, breaking the test. > > However, RFC 6265 §5.2.1 says a failed expires parse should be ignored (i.e., > treat as session cookie), so the new behavior is actually RFC-compliant. It > seems `ExpiredCookieTest` was written against the old non-compliant behavior > and needs to be updated. Would you have any guidance on the best way to > proceed? Hello @ehs208, sorry about the delay in the review. > However, RFC 6265 §5.2.1 says a failed expires parse should be ignored (i.e., > treat as session cookie), so the new behavior is actually RFC-compliant. It > seems ExpiredCookieTest was written against the old non-compliant behavior > and needs to be updated. Would you have any guidance on the best way to > proceed? I'll take a look at that test this week and see what we should do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30341#issuecomment-4604835257
