Microsoft released a patch (KB2416471) to fix a security vulnerability where a malicious party could use errors generated in the application to decrypt the data used in certain requests.  In theory, the fix should not require changes in the application.

However, it turns out that in certain situations, the patch can generate errors for pages that use CompositeScript elements.

CompositeScript elements are wonderful thing.  They allow you to take multiple javascript files and then concatenate them into a single request from the browser.  This has a couple of great benefits:

• Only one connection is used for all of these files, freeing up other connections to download other static objects
• Cache headers are set on these files for one year (the longest allowed by the HTTP standard), meaning that if the object is in the cache, the browser will not request them again.  If there is a change in the files, the generated request key will change, and the browser will automatically download the update.  No more needless 304 requests!
• You can retain the development convenience of dividing your javascript files up into logical segments, but not have to reflect this at the browser/request level

The one downside is that you can’t tell by looking at the URL alone what is inside it.  All of the them look something like “/ScriptResource.axd?d=OC6WSKC6-VBE_24rhrZ…”.  You will need to actually look inside the response to see what the contents are.  But given the major performance gains, it’s worth it.

However, there is a limitation in CompositeScript.  Request urls in ASP.NET are limited to 1024 characters, and if you include too many files in the composite script, the key gets too long, and you start getting this runtime error:

The resource URL cannot be longer than 1024 characters. If using a CompositeScriptReference, reduce the number of ScriptReferences it contains, or combine them into a single static file and set the Path property to the location of it.

At this point, your only option is to reduce the number of files included, either by splitting into two separate CompositeScript tags (and now making two browser requests), or by manually combining some of your javascript files together.

The fix included in the Microsoft patch can cause this error to appear where it did not used to.  It makes subtle changes to the way the ScriptResource.axd request keys are generated, and if you have a request that had been very close to the limit (e.g. 950 characters), it could now grow to beyond it (e.g. 1036 characters).  All of a sudden, an application that had been working fine starts generating errors.

If you have CompositeScript links that are close to the limit, you may need to break them up further to avoid errors after applying the patch.