A user reported that he could not use my web application:
http://article.gmane.org/gmane.comp.window-managers.i3.general/679
After looking into it, the problem is that the sessions.FilesystemStore is
unable to encode sessions whose serialized base64 representation exceeds 4096
bytes due to the FilesystemStore using securecookie internally (which has a
4096 byte limitation by default).
I am working around this with the patch I attached (to make the issue more
clear if my description is not enough).
To reproduce this issue, it is enough to store a 4097 byte value in your
session. If you want to use the real-world data, here it is:
sess.Values = map[interface {}]interface {}{"title":"Workspace 1 does not
respect tabbed layout setting", "description":"I have found a regression in i3.
I run i3 on OS X 10.8.2 and XQuartz\r\n2.7.4. In my configuration, I
have:\r\n\r\n workspace_layout tabbed\r\n\r\nHowever, when I start a fresh i3
version 4.3-19-g01ce4bb (2012-09-29,\r\nbranch \"master\"), i3 does not seem to
be respect the workspace_layout\r\nsetting. When I open two terminals, they
are not presented in tabbed\r\nlayout, but instead in
splith:\r\n\r\n+---------------------------+---------------------------+\r\n|
terminal 1 | terminal 2
|\r\n+---------------------------+---------------------------+\r\n|
| |\r\n| |
|\r\n| |
| \r\n\r\nThe problem only occurs in workspace 1, however. When I switch
to\r\nanother workspace, say workspace 2, and I open two terminals, they
are\r\ntabbed as I would expect them to
be:\r\n\r\n+---------------------------+---------------------------+\r\n|
terminal 1 | terminal 2
|\r\n+---------------------------+---------------------------+\r\n|
|\r\n|
|\r\n|
| \r\n\r\nInterestingly, when I close all the windows in workspace 1,
switch to\r\nworkspace 2, open two windows, then switch back to workspace 1 and
open\r\ntwo windows there, then they are tabbed as well. So, workspace
1\r\nrealizes that it should use the tabbed layout only after I've used
it\r\nsuccessfully in workspace 2.\r\n\r\nIt seems that this problem was
introduced recently. When I run i3-4.2\r\neverything works as I expect it to
work. The release version of i3-4.3\r\nhas the problem as well as today's HEAD
of the git repository.\r\n\r\n(Unfortunately I am not able to provide more
debugging information,\r\ni3-dump-log seems not to work on OS X. i3-dump-log:
Could not shm_open\r\nSHM segment for the i3 log (/i3-log-32571): No such file
or directory).\r\n\r\nAny ideas what could be the cause of my problem? I am
happy to provide\r\nmore information or test out things if
needed.\r\n\r\nThanks,\r\n-- \r\nMarcus\r\n"}
Original issue reported on code.google.com by mstpl...@gmail.com on 2 Oct 2012 at 9:09
Original issue reported on code.google.com by
mstpl...@gmail.com
on 2 Oct 2012 at 9:09Attachments: