Thursday, 13 November 2008

Fixing the IE7/MOSS/HTTP 413/Client SSL/View State White Screen of Death

Content on the Tourism WA partner sites like Australia's Golden Outback needs to be accessible by content editors over the internet. To facilitate this, we use client certificates over SSL to authenticate users. Each certificate is additionally mapped to an Active Directory account to support granular control over specific assets and provide standard "auditing" (in the MOSS version history sense) of user activity. Users additionally benefit from a single sign-on experience since IE hands off the client certificate in a relatively seamless manner.
In the image below the first box describes how client certifcates are created and provided to the content editors; the second box describes how IE and IIS authenticate the user to MOSS via AD.

This approach looks pretty nice on paper apart from the manual task of creating the client certificate and the potential distribution security. Our external content editor user base is fairly small and well-known, however.

Following the launch of the first partner site using this security model, we came across a painful situation I'll describe here but hope you never encounter in the field. If you have come across this problem, hopefully this post will steer you in the right direction. 

So the problem: 

When attempting to save, check in, or publish a page, IE content editors were presented with a white screen (a page with nothing in it, more specifically) in a relatively short timeframe. The problem appeared to be sporadic and definitely affect some pages but not others.

Inspecting the content editor's machine revealed no hardware or software issues and nothing was logged to the client's event logs. The HTML source was nothing special with the IE Dev Toolbar telling the same story:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<META http-equiv=Content-Type content="text/html; charset=windows-1252"></HEAD>

Although some basic IE security and JS settings were tweaked, friendly error messages were already turned off. As our initial user base was regionally-based and we mistakenly believed we couldn't reproduce the problem on the local network, we initially ascribed the problem to a lousy, congested regional network connection. I say we mistakenly believed we couldn't reproduce the problem because we generally use the non-SSL-secured internal site at head office due to an unrelated issue. 

This wasn't a lot to go on and we struggled to diagnose the problem while waiting for the installation of a WAN accellerator upgrade to our own regional office to prove or disprove our theory about the network infrastructure. Meanwhile, our third partner site came online and the content editors logged the same issue; this time, those content editors were sitting in Perth on metropolitain ADSL 2+ wires.

With the installation of a broadband connection at home I decided to see what I could find out outside the corporate environment. I logged into to one of the secure sites and got lucky--I was finally able to reproduce the problem on one of every five or so attempts to save a rather large page. 

With that achievement under my hat I fired up my trusty friend Fiddler 2 and reloaded the site. As I mentioned above, the partner sites are delivered to content editors over an SSL-secured (443) connection; in other words, that means inspecting the HTML request/response data outside the browser would normally be a bit tricky. Luckily Fiddler 2 makes this easy--you simply need to check the Decrypt HTTPS traffic checkbox in the Fiddler settings (under Proxy Settings) and Fiddler will present you with the goods. 

In my case that was step one but step 2 meant I'd also have to hand over a valid client certificate since Fiddler essentially does the man in the middle thing to pull off the SSL decryption bit. Fiddler's documentation is pretty good on this subject so after exporting my existing certificate with a .cer extension I dropped it into My Documents\Fiddler2\ClientCertificate.cer (named exactly as shown). At long last I could not only reproduce the problem but I could even see under the covers of the HTTP protocol!

And it was that simple: hitting the same problem page a few times and Fiddler told me it was all about a lousy HTTP 413 error--all this for a bloody error code IE should have been showing me in the first place. 

Here's the request:

POST /en/ThisPageIsTroubba.aspx HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/, application/, application/msword, application/xaml+xml, application/, application/x-ms-xbap, application/x-ms-application, application/x-shockwave-flash, application/x-silverlight, application/x-silverlight-2-b2, */*
Accept-Language: en-au,en-GB;q=0.5
Content-Type: application/x-www-form-urlencoded
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Length: 71069
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: WSS_KeepSessionAuthenticated=443; MSOWebPartPage_AnonymousAccessCookie=443; s_cc=true; s_sq=%5B%5BB%5D%5D
HTTP/1.1 413 Request Entity Too Large
Content-Length: 0
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Sun, 02 Nov 2008 10:47:22 GMT
Connection: close

"What is an HTTP 413 error," I asked, just like you may be doing now? It means the server rejected the request because it considered it too big. Weird, considering the request was only just over 71KB but at least we could rule out the network--a good thing because a lot of our future content editors are very much regional.

The w3c tells us the following about HTTP 413:

"The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.
If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again."

I mentioned page weight previously and the title of this posting also ties in viewstate. Why? I've already suggested the white screen problem seemed to affect some pages but not others. While investigating this problem, I noted the viewstate on most of the anonymous partner site pages is very low at a <2KB.

Still with me? 

We're currently running on Windows 2003 and IIS 6.0. When IIS has to deal with client certificates, the server uses the UploadReadAheadSize metabase property during the SSL preload process to determine the maximum buffer size for the incoming request. The default buffer size is 48KB to prevent denial of service attacks and for that reason Microsoft doesn't recommend setting it too high. In our case, the 71KB request was considered too large and IIS wouldn't let it through. Why the save/check-in/publish worked sporadically I can't say, but increasing the value assigned to this property instantly fixed the problem. We increased this setting on every relevant IIS web site using this command:

cscript adsutil.vbs set w3svc/1/uploadreadaheadsize 204800

Note the setting represents bytes, not kilobytes, and the TechNet article on changing this is incorrectly specifies a value of 200.

In theory the HTTP 413 should have come up in the server logs but if it did, we never caught it. 

For more information about the metabase changes, the following blog posts may be of use:

Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development -

Great SQL Server Database Performance Article

Zach Nichter has written a very approachable article for TechNet Magazine on the subject of SQL Server performance measurement. It's brief and very much to the point, covering performance counters, profiling, and dynamic management views. It's by no means MOSS-specific but nonetheless applicable and the author obviously has a wealth of experience on this topic.

"Optimizing SQL Server CPU Performance"

Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development -

Tuesday, 11 November 2008

Firefox 3 Penetration

I was vaguely surprised when I checked our Omniture stats for the last three months: 58.6% of Firefox users visiting all of the eMarketplace sites over the last three months were using version 3. So it's official, we're now supporting IE6/7 and FF2.x/3 across the MOSS-based anonymous sites.

Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development -

Stacking Windowed Elements and Flash Movies with z-index and wmode in IE

There exists a common misconception z-index will solve all of your DHTML stacking problems. While this is true for DHTML elements, the assumption falls down in the face of Internet Explorer and the way this browser treats "windowed" components like drop down lists based on the select tag. Flash objects aren't immune but for different reasons. Firefox will honour stacking orders for all elements but this is not the case when you're dealing with IE6/7. Windowed elements maintain a different stacking order than DHTML elements (they're added to a different plane than your windows elements) and therein lies the problem.

IE7 is better than IE6 when it comes to the select element but Flash requires some additional finessing, which I'll detail below. If you're still supporting IE6, consider using an IFrame (perhaps dynamically positioned) between your windowed component and your DHTML object to mask the underlying windowed component. The concept is generally referred to as an "IFrame shim". Don't forget, IFrames can be configured with a transparent background; either way, simply point the IFrame URL at nothing. The IFrame is no longer a windowed element as of IE5.5; although some people don't like IFrames for security and because they're frames, in this case the IFrame is your friend because it bridges the gap between windowed elements and windowless elements. The one main gotcha with this approach is how the user interacts with an IFrame: button clicks and mouse actions will be sent to the IFrame and the underlying content won't be interactive while the IFrame is visible.

Flash--being Flash and an ActiveX-wrapped plugin--is a different beast. IE places embedded content in a DHTML layer above all other layers by default and this is not always where you want your Flash content. On the home page, a fancy combination of DHTML and Flash elements known as the Tourism Australia overlay sits above the Flash banner (it's only visible to international site visitors); the DHTML-based navigation likewise has to sit above the central "experience panel" and the global site selector drop down in the right column.

To reign in your Flash objects and their stacking order you need to use an extra parameter named wmode:

&lt;param name="wmode" value="opaque" />

By doing so the Flash object and surrounding DHTML elements will team up to honour z-index styles as you intend. It's also a good idea to add a corresponding wmode="opaque" attribute to your element tag. Opaque and transparent modes may compromise your animations and video--we haven't had any problem on our sites, however, and use both animations (the wipe) and video. 

Here are a few additional tips for dealing with Flash:
  • Add Flash elements to a predefined placeholder element using JavaScript to ensure the object is activated automatically (otherwise users will have to click the Flash movie to run it and movies that should play automatically without user interaction may not start when the page loads). SWFObject will do this for you but it's really easy to write the JavaScript into your existing .js files, thereby avoiding the need to weigh down your page with yet another script library.
  • Don't rely solely on the embed tag. Use the object tag for IE and nest an embed tag within it for Mozilla and everyone else.
  • Always explicitly configure the wmode parameter as a child of the object tag and an attribute of the element tag.
  • Avoid the wmode "transparent" setting unless your Flash movie actually has transparent sections. Use "opaque" in most cases to increase rendering performance. The default is "window".
  • Consider a Flash alternative like Silverlight ;-)
Microsoft's windowless vs windowed summary:

Adobe's semi-useful KB article about wmode:

How to create an IFrame shim:

Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development -

Monday, 10 November 2008

CSS Style Guide

For a brief but useful CSS style guide see

The tip about cascading style names caught my eye in particular--it's incredible how much code I've seen that simply ignores this simple concept at the cost of breaking things.

Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development -

Thursday, 6 November 2008

Microsoft offers startups free software

Microsoft has just launched the BizSpark program to provide startups with a complete fit out of MS software for next to nothing. You have to associate yourself with a 'network provider' (eg. a venture firm) and you pay $100 to exit the program, which is forced after three years; apart from any stake the venture firm may take in your business and the exit fee, the software is free. There are some additional prerequisites to meet as well.

Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development -

Third Internet-Facing MOSS Site Launched

The third of five regional tourism organisation (RTO) sites built on MOSS 2007 launched yesterday afternoon: After this lot we've got another 25-odd partner sites to go--all to be run on the same platform.

This site replaces its MCMS 2002-based legacy equivalent and follows on the heels of the ASW and ANW sites. 

Congratulations to AGO and the team!

Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development -