Cookies and HTTP
Bob Denny
sent by the browser when working with a TiddlyWiki that lives on a
remote server. There are a lot of things which are persisted in cookies
at the browser, and which do not need to be sent to the server.
As it is, the cookies set by the option logic and probably most plugins
that bake their own (rather than using options) have the usual path
attribute of '/'. This means that the browser is supposed to send that
cookie with every request. As plugins and options proliferate, this
could get biiiig.
The simple fix would be to change the path attribute of cookies being
baked for browser use only to something ridiculous like
/ag8473/g0118f/goperiug, a path that is rather not likely to exist on
the server. The browser will not send the local cookies in its
requests, keeping the requests minimal.
Bob Denny
to prevent the cookie from even being stored locally on IE! Ratzafratz!
There's gotta be a way...
Jeremy Ruston
> to prevent the cookie from even being stored locally on IE! Ratzafratz!
> There's gotta be a way...
Shame, I'd definitely be interested in a simple fix for the
cookie-sending behaviour,
Cheers
Jeremy
> >
>
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
Bob Denny
> cookie-sending behaviour,
Yeah, some more research uncovered a wealth of discussion on setting
cookies with paths and domains other than that of the server.
Apparently, Mozilla wil let you be free-wheeling when setting cookies
locally (document.cookie = ) but IE apparently uses the same filtering
logic for that as they do for cookies being set by remote servers. I'd
love to see an alternative too.
Thinking about this a bit more, I believe that the cookie mechanism is
sub-optimal for several reasons. (1) I have lost various cookies for no
apparent reason when full-refreshing IE6 (shift-refresh). (2) There are
limits on the number of cookies and their sizes,with 20 being a cookie
limit. I'll try to find out more. These are -minima- and not hard
limits, but we're pushin' it. Per RFC2109:
· at least 300 cookies
· at least 4096 bytes per cookie (as measured by the size of the
characters that comprise the cookie non-terminal in the syntax
description of the Set-Cookie header)
· at least 20 cookies per unique host or domain name
The limit of 20 applies even to cookies set when reading locally, since
"local" is considered a domain. The ray of hope is the 4096 byte limit
per cookie. We could bundle all of the option states into a single
uber-cookie. Just a thought for the future.
Jeremy Ruston
> per cookie. We could bundle all of the option states into a single
> uber-cookie. Just a thought for the future.
I've also thought of doing that, seems quite sensible.
Bob Denny
HTML forms. My wiki now has a bunch of forms and I ran out of cookie
slots. The plugin now uses a single cookie for all of the fields in all
of the forms (field names must be unique unless you want them to be
"shared" which I do in some cases).
This was easy to do, and we probably ought to start thinking about it
for the config items. I know it will cause folks to lose all of their
settings, and we'd have to do something to clean out the old separate
ones (since they have very long lifetimes).
I used a format of pfc=name:value&name:value... (pfc == persistent form
cookie). I believe the size limit is 4Kb, which should be plenty.
I wrote:
> We could bundle all of the option states into a single
> uber-cookie. Just a thought for the future.
Jeremy Ruston
Bob Denny
Bob Denny
storing config.options stuff in my TW 2.0.2 with hijack code in
MarkupPostHead (required, loadOptionsCookie() happens early in main()).
It was a bit messy because UploadPlugin hijacks the options cookie
things for its password persistence. I ended up having to put support
for BidiX's password and save-chkbox into my hijack and comment out his
hijack. Clearly, consider this a "personal solution".
I did post a note about losing cookies in IE, and it seems that I was
bumping into the limit, causing old ones to be dumped. This new
approach solves that problem. Option persistence in IE has been 100%
since the change.
Bottom line, though, is that with the change to loadOptionsCookie() and
saveOptionCookie() all of my plugins are working except font size - it
appears to set its own cookie txtFontSize outside of the common calls.
No big deal, there are so few cookies not that it doesn't matter!
Yann Perrin
http://www.phpied.com/json-javascript-cookies/
which may be helpful, as it provide a small footprint solution.
what do you think ?
--
Yann.
http://yann.perrin.googlepages.com
Bob Denny
inflation and bumping against the single-cookie size limit (whatever
that is... 4KB???). It's not very well documented or disclosed by
browser specs.