1)Doubles quotes should be a part of the value (RFC6265 S4.1.1)
2)"Relaxed" mode should use \r \n\ and \0 as terminators according to Chromium source (https://chromium.googlesource.com/chromium/src.git/+/master/net/cookies/parsed_cookie.cc)

…0029 test)

… correct way).

According to S5.2.4 we should fallback to the default-path only if the path attribute-value is empty or if the first character is not "/".
Meanwhile, then we are query cookies from the store we should use path-match algorithm from S5.1.4 instead of path permutation based algorithm.

… correct order for the cookies which are set synchronously. So we are using high-resolution time now where possible.

…in browsers (see: https://github.com/ChromiumWebApps/chromium/blob/b3d3b4da8bb94c1b2e061600df106d590fda3620/net/cookies/parsed_cookie.cc#L64)

…values is '/' we should fallback to the default-path. Previously code doesn't considered the case then we have two path attributes. Now we always assign null explicitly if the path attribute is empty or '/' (Fixes PATH0030 IETF test)

… meanwhile previously used regexp doesn't allowed years that starts with zero (e.g. 07). Also, it allowed 3-digits year, which is incorrect

According to RFC6265:
 time            = hms-time ( non-digit *OCTET )
 hms-time        = time-field ":" time-field ":" time-field
 time-field      = 1*2DIGIT

Previous regexp doesn't allowed 1 digit minute/second time fields.

According to RFC6265  S5.1.1:
  month           = ( "jan" / "feb" / "mar" / "apr" /
                       "may" / "jun" / "jul" / "aug" /
                       "sep" / "oct" / "nov" / "dec" ) *OCTET

So, spec allows suffix for the month.

Use the exact grammar productions from the RFC for the time and day-of-month. Then perform correct validation (e.g. we should fail on "Sat, 15-Apr-17 91:22:33 21:01:22" because first met time token was incorrect. Previous approach just skipped first token, which is incorrect according to the RFC and doesn't matches browser's behavior (see: https://github.com/ChromiumWebApps/chromium/blob/b3d3b4da8bb94c1b2e061600df106d590fda3620/net/cookies/cookie_util.cc#L189)

Previous algorithm failed at the last day of the current month. This was caused by the fact that setUTCMonth method was used. According to MDN(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/setUTCMonth) it accepts two parameters. If second parameter (dayValue) is not specified then V8 uses current day value. So if you are setting April as month, and current system date is March 31 then if will be resolved as May 1 which doesn't works for us. Therefore, we will parse tokens separately and then create new Date() object using Date.UTC()

Previous algorithm failed at the last day of the current month. This was caused by the fact that setUTCMonth method was used. According to MDN(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/setUTCMonth) it accepts two parameters. If second parameter (dayValue) is not specified then V8 uses current day value. So if you are setting April as month, and current system date is March 31 then if will be resolved as May 1 which doesn't works for us. Therefore, we will parse tokens separately and then create new Date() object using Date.UTC()

Use runtime creation index instead of hrTime. Track cookie.creation modifications by
storing original UTC timestamp and comparing it with the actual cookie.creation.getTime().
If creation date was modified we fallback to the plane dates comparison.

…n (fallback from runtimeIdx)