The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.I have some code that works just fine when I am using SESSION_CACHE_STORAGE_DB_CORE and SESSION_CACHE_STORAGE_SESSION modes. When I switch to SESSION_CACHE_STORAGE_COOKIE, I start getting flaky results.
As far as I can tell, the problem is when I am trying to stuff too much data into the session.
Since cookies are limited to about 4k by all browsers, I am not sure what can be done about this. Storing the data as
base64_encode(gzdeflate(serialize($data)))
may help things to an extent, but the limit still is there.
I am mainly reporting this so that if anyone else runs into the problem, they can see what is happing.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | session_cache-compression-2204121-06.patch | 6.19 KB | mpdonadio |
| #2 | session_cache-compression-2204121-02.patch | 2.46 KB | mpdonadio |
Comments
Comment #1
rdeboerThanks for your report. I believe you are right. Cookies have a size limitation and compression can only do so much.
I'll make a note of it in the README.
Comment #2
mpdonadioHere is a patch if you are interested. Two changes:
In session_cache_set(), when cookie mode is enabled, the data gets compressed. If the compressed data is longer than 4000 bytes, then a watchdog() gets logged.
In session_cache_get(), the inverse gets done.
I am seeing 2:1-3:1 compression ratios. This may help some users.
I didn't tackle the README.
Comment #3
rdeboerThanks for the patch Matthew!
I'd rather see the compression being a config option, especially for inspection/debugging purposes, but that is easily done.
What sort of data are you putting in your cookies that exceeds the limit?
Rik
Comment #4
mpdonadioI can re-roll with a compression option when I get a chance.
I have a site where I have paged search results. Client want BACK, PREV, NEXT links on the node pages. So, to avoid polluting the URLs with the parameters, I am running the search w/o paging, and getting the list of nids. I then rerun the search paged for presentation. The list of nids, and the search query are getting saved in the session. Some of the searches return a lot of results, which end up beyond the 4k limit.
Comment #5
rdeboer@mpdonadio:
Hold off on the patch. I've been thinking about it and feel we may want to solve it in another way. Will get back to you.
Regarding your use-case of client-side paging.... have you had a look at http://drupal.org/project/table_trash ? The project page has a link to a live demo.
Rik
Comment #6
mpdonadioAlready had patch made before I read this. Took 5 min.
Adds a configuration variable to control whether cookies get compressed or not. Did not edit the uninstall, as it does a blanket deletion of variables in the namespace.
Comment #7
rdeboerHi Matthew
I appreciate the patch, but have decided not to incorporate it inside Session Cache API.
Don't get me wrong... what you've brought to the table is very useful functionality. But compression and checking for data size are general functions that can be applied outside Session Cache (and apply to all session storage methods), so I don't really feel these are the responsibility of the module.
I like to keep this module as lean and simple as possible.
Thank you for your contribution -- I didn't know about
gzdeflate.Rik
Comment #8
mpdonadioIt's cool, I spent about 20 min total on this.
I would just mention that if compression and size checking need to be done outside the API, then serialization does, too, as that is the only way you can check size. It also means that you end up serializing the data twice (both in and outside the API). No biggee, it adds 6(?) extra bytes, but you have the overhead of doing it twice.
Comment #9
rdeboer@mpdonadio, #8
Re "... if compression and size checking need to be done outside the API, then serialization does, too, as that is the only way you can check size " .
That is a valid point.