Create a new cookie with expires initialized with the MAX_DATE

[jgiovaresco]

We are using the MAX_DATE value from tough-cookie

Closes #2482

[CLAassistant]

All committers have signed the CLA.

[jgiovaresco]

@develohpanda
I have several questions about this:

• First, I'm using as MAX_DATE the same value used in tough-cookie. However, as you can see, the resulting date is sometime in 2038. I've tried to use the max value from the spec (i.e., 8640000000000000), but it seems that httpSnippet throws an error when the HAR contains a cookie with such date. I'm wondering if the max value I currently use is ok or would you prefer I used the spec max value and therefore fix httpSnippet?
• I'm wondering if you are expecting in this PR the use of the date picker you mentioned on the issue 🤔

[develohpanda]

First, I'm using as MAX_DATE the same value used in tough-cookie. However, as you can see, the resulting date is sometime in 2038. I've tried to use the max value from the spec (i.e., 86400000000000), but it seems that httpSnippet throws an error when the HAR contains a cookie with such date. I'm wondering if the max value I currently use is ok or would you prefer I used the spec max value and therefore fix httpSnippet?

How does tough-cookie behave with the spec max date? Note that it is one extra digit, and I'm assuming tough-cookie chose to use their number for a performance benefit. Secondly, is it a trivial fix in httpsnippet/where is the root cause in that library? My gut would say to use the tough-cookie max value as there should basically be no real-world impact for Insomnia with this.

I'm wondering if you are expecting in this PR the use of the date picker you mentioned on the issue

Nope, a small patch fix for the original bug is fine. The date-time picker is more a feature request and I would do it separately.

[jgiovaresco]

I've just noticed that I forgot 0 zeros to the number... it is 86400000000000

How does tough-cookie behave with the spec max date?

It seems to behave correctly, a cookie is generated with a date in a far far far future 😅 (Sat, 13 Sep 275760 00:00:00 GMT)

The issue in httpSnippet is kind of tricky.
The root cause is that httpSnippet performs a validation on the har provided, and it is this validation that fails. It uses the following package har-validator and use an ajv validation with this json schema.
I don't know why but it seems that 275760 is too big to be a year using this validation 🤯

Edit: I've found the rules for date validation using ajv: https://tools.ietf.org/html/rfc3339#section-5.6. It expects 4 digits date 🤔

If you're ok with using the max value of tough-cookie I will keep that 😅

[develohpanda]

Great investigation 👏

If you're ok with using the max value of tough-cookie I will keep that 😅

IMO the tough-cookie max date is sufficient (you could also choose to use the number representation of 12/12/9999 since that is the technical maximum achievable by the current libraries being used 😆)

@DMarby would you have any further notes to add here around what value to use to represent the max date for cookie expiry?

[DMarby]

@DMarby would you have any further notes to add here around what value to use to represent the max date for cookie expiry?

Sounds reasonable to use the tough-cookie max value, I guess we can revisit the decision in 2038 if needed 😅

[develohpanda]

As they say, that's a problem for future me 😂

[netlify]

Deploy preview for insomnia-storybook ready!

Built with commit c5062ef

https://deploy-preview-2908--insomnia-storybook.netlify.app