B2TR Cookie changes in Excel Services EWA

EWA allows users to work on workbooks in a truly thin manner. One of the things that were important for us to do, was to allow session information to be kept around as the user was navigating around a Sharepoint site. This was doubly important for us because the actual EWA is loaded within an IFrame which makes it more susceptible to losing information due to the browser refreshing etc.

In Beta2, there was a problem that was, thankfully, not hit often where, if in the same session of IE, users would open a very large amount of EWAs, they would suddenly start getting errors in the form of “Bad Header” – no explanation or anything. Just a black-on-white error saying “Bad Header”.

We finally figured out that there is a limit to the amount of data IIS will allow the header to have and that we were going over that limit. To fix that, we added a mechanism that would age our cookies when 75% of that size is reached. That solves that hard-to-hit bug.

The limit in IIS, by default, is 16k. Excel Services takes 75% of that limit and uses that as the threshold where it will start aging its own cookies, freeing up space.

With post-b2tr releases, Excel Services also looks at the registry to check if that value has been adjusted by the administrator and use the adjusted value to figure out the size where aging will start happening (again, 75% of what the limit is).

For more information about how to adjust this value, check out this article, specifically, information about the MaxRequestBytes key.

It is important to note that IE will allow only 20 cookies for a given domain name at any given moment. Because of this, if you are browsing around more than 20* EWAs in the same IE session, you will notice that older pages "forget" your session. This is expected. In the next post, I will discuss a featurette we added that will allow EWAs used in dashboards to not have any cookies associated with them (and thus allow for more interactive EWAs to "stay alive" during a given IE session).