xtim
Tuesday, March 03, 2009
Large cookies
Best kind.
There are currently two codebases which work together to serve our web pages and page images.
By far the biggest is the Java application which runs within Tomcat and knows about all our abstractions - members, subscriptions, books and magazines.
The smaller piece of code is an Apache perl module which grants or denies access to the page images depending on what you're allowed to see.
These two pieces of code communicate through cookies sent via your browser - the Java code knows what you're allowed to see and it sets a cookie to reflect that. The browser supplies this cookie when requesting a page image and the perl module decodes it before deciding whether to send you the file you asked for.
There are complications like digital signatures in there to maintain the cookie's integrity through this conversation.
The problem is that some accounts (for example our UK shop) now have many subscriptions. It becomes inefficient to squash all this information into a cookie, and we're occasionally encountering hard limits on cookie length.
Time for a new solution.
The new approach follows Amazon's S3 model, where each image request will include an expiry date and a cryptographic signature. The perl module can just check the expiry date against the current system time, verify the signature and serve the file if all is ok. No cookies required.
On the Java side we have to generate the expiry timestamps and signatures for each request.
Java first.
T
Labels: cookies, projects, tomcat
Friday, January 30, 2009
The problem with the button cache
is that I misconfigured it.
We started to see people getting logged out of the site unexpectedly while in the middle of a session.
Finally realised that mod_cache is caching the Set-Cookie: headers in the button image responses. The only cookie we would set there is if a request has arrived without an existing session, in which case we set the cookie to indicate our main shop account.
When your cached button image expires, your browser would request the copy cached in apache. Apache would deliver that, along with the Set-Cookie header if one had been stored. Then whoosh - you're back in the shop.
Ooooooh dear.
The fix is easy once you realise that you need it - use
CacheIgnoreHeaders Set-Cookie
to tell mod_cache not to cache the cookie header. That's now in place and is working (I've checked the stored headers and they're clean). Hoping that's the end of it!
T
Labels: caching, config, cookies
Wednesday, November 19, 2008
Tomcat and cookies
Cookie handling always seems to complicate the deployment of new server components. Tomcat 6.0.16 introduced a few changes in the way cookies are managed - the upshot is that some cookie values may acquire surrounding double-quotes.
This is transparent to the servlet, as tomcat strips the extra punctuation off before handing the value back to the servlet on the next request.
If you're using the cookies in other components (for example apache plugins) then they need to be updated too. A new authorisation filter is now in place which handles this, ready for a tomcat upgrade later this week.
T
