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: , ,


Comments: Post a Comment

<< Home

Powered by Blogger