Comments (2)
Hey Francisco,
This seems like a reasonable strategy to take, given that each browser vendor can choose to implement their own arbitrary limits. It's worth noting that RFC6265 provides a little bit of guidance in terms of what expectations should be met, at a minimum:
6.1. Limits
Practical user agent implementations have limits on the number and
size of cookies that they can store. General-use user agents SHOULD
provide each of the following minimum capabilities:o At least 4096 bytes per cookie (as measured by the sum of the
length of the cookie's name, value, and attributes).o At least 50 cookies per domain.
o At least 3000 cookies total.
The real bummer is that there's multiple scenarios that could prevent a cookie from being set properly, and it's not always (if ever) possible to determine what the exact cause is, given the loosey-goosey limits. Cookies could be disabled in the browser, an individual cookie could be too large, there could be too many cookies for a single domain, or there could be too many cookies in total.
It occurs to me that it's also theoretically possible that the Cookies.js enabled
property ends up being false
due to one of these limits having been hit, but while browser cookies are still enabled. Perhaps the end result is equivalent to if cookies were truly disabled, but it seems semantically incorrect.
In any case, it could be good to check if a cookie actually got set, and if not, throw an error. However, I don't think we can easily include why the cookie failed to be set in the error message (beyond giving possible suggestions/ideas as to what the cause might have been).
Related issue: #49
As a side note, the idea of having a cookie with 4+ KB of data in it kind of gives me the heebie-jeebies. This isn't to say we shouldn't loudly throw errors when a cookie fails to be set, but it seems a gross abuse of cookies to attempt to cram that much data into one. But I also honestly don't understand why anyone would use cookies for anything more than authentication/identification/anti-CSRF tokens (which should be HttpOnly anyways) and simple UI preference settings (grid sorts, applied filters, etc).
from cookies.
In addition to browsers failing silently with single large cookies, HAproxy, Apache2 and others may reject all requests or responses which exceed the maximum HTTP header size configured in the server. While browsers may reject server responses (or the servers themselves).
It could result in the inability of the server to remove the offending cookies via a Set-Cookie header, by being prevented from even receiving requests from such a browser.
I have encountered this when I had to move PHP sessions into cookie storage to enable scalability and fix some problems with too many sessions stored on one server, for a legacy application at the company I work for.
As a side note, Brotli helped a lot :)
Estimating the header size was the way to go, and then destroying data inside cookies or entire cookies if size got out of control (memory leaks in these storage cookies sometimes).
What I mean is: the size of a single cookie is not that important, but the size all all HTTP headers which may contain multiple cookies.
from cookies.
Related Issues (20)
- `_isValidDate` method failing in IE11 HOT 9
- Comparing to `js-cookie` HOT 2
- better way to set Cookies.default HOT 2
- Always get true on edge browser even i have disabls all cookie in browser HOT 5
- Share cookie data between two different domain HOT 1
- Can't read document.cookie that contains the value % HOT 1
- Session cookies HOT 1
- Type of value? HOT 4
- Doesn't work in browser environment HOT 1
- Visual Composer Issue Can anyone solve this..? HOT 4
- Typescript fails to find type definitions HOT 1
- Doesn't work. Uncaught TypeError: Cannot read property 'set' of undefined HOT 1
- Add optional default value for get()
- if my cookie value is '👽👽👽👽' will cause URIError: URI malformed HOT 1
- cookies.js Cookie HOT 1
- Strange regexp replace HOT 1
- How can i update a cookie without resetting its expiry date HOT 1
- add support for samesite
- dead repo? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cookies.