Contact Emails:
awi...@chromium.org, mike...@chromium.org
Explainer:
https://github.com/httpwg/http-extensions/issues/1340
Spec:
https://github.com/httpwg/http-extensions/pull/1563
TAG review N/A: this change is already specified in RFC 6265bis, is (mostly) implemented in at least one browser, and is already partially implemented in Chrome (this improves spec compliance).
Summary:
Enforce limits on the size (in bytes) of cookies set by HTTP responses (Set-Cookie header) and via JS APIs (document.cookie and CookieStore).
Motivation:
RFC 6265bis has long suggested a limit on cookie sizes, but different user agents have implemented limits in subtly different ways, creating interoperability issues and providing a browser fingerprinting mechanism.
After the spec change corresponding to this Intent, user agents are now required to limit the sum of the lengths of the cookie's name and value to 4096 bytes, and limit the length of each cookie attribute value to 1024 bytes. Any attempt to set a cookie exceeding the name+value limit is rejected, and any cookie attribute exceeding the attribute length limit is ignored.
Risks:
Interoperability and Compatibility
Implementing this change in Chrome would improve interoperability. The new limits are very similar to what Firefox enforces (4096 bytes limit on name+value, and 1024 byte limit on the Path attribute, but no analogous limit on the Domain attribute).
Metrics in Chrome indicate that this change is web compatible:
1) Chrome currently enforces stricter limits on the entire Set-Cookie line (including the name, '=', value, and any attributes) to 4096 bytes, so the standardized 4096 byte limit on name+value only means any cookies that are currently accepted will not exceed the proposed 4096 byte name+value limit.
2) The overwhelming majority of cookies either have no Path attribute, or have a Path attribute of '/'. The mean Path attribute length was 1.15 bytes. There were exceedingly few cookies in the sampled data with a Path attribute of over 1024 bytes, only 0.0000003% of currently accepted cookies (and such cookies already do not work in Firefox), which would be rejected after the proposed change.
3) There were almost no cookies in the sampled data with a Domain attribute of more than 1024 bytes. The mean Domain attribute length was 9.58 bytes. Only 0.000000002% of currently accepted cookies would exceed the 1024 byte Domain attribute limit and be rejected after the proposed change.
4) Lengths of other cookie attributes are not relevant, as they take either enum or boolean values.
Any existing cookies on disk that violate these size limits will remain in the cookie store. This is due to implementation considerations: cookies are stored in parsed form rather than as raw Set-Cookie lines, and once a cookie has been parsed, it can be impossible to tell whether its original Set-Cookie line exceeded the limits. The number of cookies to which this applies is expected to be insignificant.
Ergonomics
No performance impacts.
Activation
None required.
Debuggability:
DevTools debugging support will be implemented along with this change. Rejected response cookies are already shown in DevTools in the Network panel, with a status explaining why they were rejected. Another status will be added to annotate cookies rejected due to size limits.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes. WPT coverage has been added.
Link to entry on the feature dashboard
https://chromestatus.com/feature/4946713618939904
Requesting approval to ship?
Yes
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkXAECTLD0hn4L3aUFYA3MnRDJ9BZn8JcZNQgeoDLnm_qg%40mail.gmail.com.
LGTM1 - seems unlikely to cause serious breakages since it will typically be more accepting than before, and it being the same as at least one other browser engine.
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkUQawArW%3DhN22YuvMxksMFDo9KY-AoeBw8LNuzAve%3DN0A%40mail.gmail.com.
LGTM1 - seems unlikely to cause serious breakages since it will typically be more accepting than before, and it being the same as at least one other browser engine.
/Daniel
On 2021-07-29 22:58, Andrew Williams wrote:
Hi Yoav,
You are correct - these size limits apply only when each individual cookie is parsed or set (for example, when parsing each Set-Cookie header in an HTTP request). This proposal aims to replace Chrome’s existing limit on the size of cookies it sets with a similar one that's more in line with what other browsers enforce, and that complies with the latest version of RFC 6265bis.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkXAECTLD0hn4L3aUFYA3MnRDJ9BZn8JcZNQgeoDLnm_qg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkXAECTLD0hn4L3aUFYA3MnRDJ9BZn8JcZNQgeoDLnm_qg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.