Transparent iframes

Firefox by default makes all iframes transparent (no effort required from the developer) if you don't define the background css property.

IE requires extra effort to ensure that the hosting page as well as the iframe's content owner both wanted this iframe to be transparent (few may agree with IE's approach while most will condemn M$). Whatever, here is the css (for page loaded in the iframe) and iframe tag declaration that works flawlessly:

body{
    background: transparent;
}

client side storage: persistjs

Current project that i'm working on, works like a plugin to an existing website. To match to the scale we are targeting, we decided to go the stateless way on the server side; so that we don't necessarily need a sticky behavior on the server side. Now this raised requirement to store state and related data on the client side. On each request client sends the "exactly required" state to the server and server decides on things that need to be done.

If you've read my previous post on cookie size limitations in browsers; you would understand this cannot be done at all. To add to the problem, this project being a web plugin to an existing site, needs to share the cookie space with them and their already existing plugins. We were really concerned if we end up messing with their cookies or they end up messing up with ours (given the size limitation).

And then we found persistjs. You should read all the good reasons why you should use persistjs here. In short, it tries to find multiple possible way to store and retrieve data on the client side. If one method fails, it fall backs to the next available method. The last being cookies and before that flash. This was a relief to us because web stats show ~99% browsers support flash and ~70-80% already have flash plugin installed. In all good/bad probablities, we will end up with a browser which supports one of the client side storage supported by persistjs. It currently supports the following:

• flash: Flash 8 persistent storage.
• gears: Google Gears-based persistent storage.
• localstorage: HTML5 draft storage.
• whatwg_db: HTML5 draft database storage.
• globalstorage: HTML5 draft storage (old spec).
• ie: Internet Explorer userdata behaviors.
• cookie: Cookie-based persistent storage.

Not only that, if we land up to a backend other than the cookie; minimum supported size is ~100KB. Good enough for us. :-)

Thats it for now. We seem to be in good shape on this side. Soon we will be going for full throttle load testing. Will share the results then. Till then, merry christmas (belated) and happy new year (in advance). [;-)]

Browser's limitation on cookie

Interestingly, now most of them have come to a standard value on their limits. If you've ever worked on client side (i.e. javascript coding), you would really appreciate this and understand why its worth mentioning here. Here are the details:

Per domain limits

1. Firefox - Both 2.x and 3.x allow 50 cookies per domain
2. IE - Until IE6.x they supported only 20 cookies per domain and IE 7 and above this limit has been increased to 50 cookies per domain
3. Opera - Opera 9 allows only 30 cookies per domain
4. Safari - No limits

Maximum Cookie Limit

1. Firefox - Both 2.x and 3.x allow 1000
2. IE - Some posts suggested its 300. ^*
3. Opera - 65536
4. Safari - No limits

Maximum Cookie Size Limit

1. This is almost uniform across the browsers (because they try to adhere to RFC 2109(Section 6.3) and limits to ~4KB = 4096 bytes

If you ever exceed any of these limits, browsers may behave differently. IE and Opera use LRU to decide which cookies to delete. FF seems to be using something different from LRU ^*.

So if you follow Graded Browser Support methodology for your website, here are the recommendations:

1. Keep your cookie count to <=30 per domain. Remember that subdomains can access root domains cookies as well (so xyz.abc.com can access cookies for abc.com domain)
2. Cookie size should not be more than 4096 bytes
3. Use some of the standard libraries YUI Cookie or Ext.util.Cookies for cookie handling

And never forget that cookies are an overhead for any website. Most of the browsers would append them to each request that is sent from the client side; some of them are smart enough to figure which particular "path" really needs them (this depends on which path the cookie was set for). And there is limit on the header size that a server can handle, for example Apache puts a limit of ~8KB. I don't know about others ^*.

* - I did my part of research but ended up with no results. If you've any concrete information, please share with links in comments