I have just spent an intense few hours crawling all the JavaScript files in our application (and there are a quite a few) fixing an issue introduced with our upgrade to the .NET framework 3.5. The entire afternoon in fact was spent fixing a single issue: our AJAX calls had stopped working.

The first hurdle was due to a slightly off-the-norm setup we have for our website. In order to save replicating code across the various websites that make up our solution, we opted for a common virtual directory that serves common assets like JavaScript, images and so on. With a little jiggery pokery, it also allows us to use shared .ascx controls. When we upgraded to the 3.5 framework, the upgrade wizard scans the projects and changes any references that should be pointing the new 3.5 versions. Not all references were changed, as the latest framework sits on top of the 2.0 framework, rather than replaces it. Unfortunately, the upgrade wizard could not figure out that our virtual directory project was not an application at all, so it created an unneeded web.config for it . However, removing that made little difference and it took me quite a while until I found that there were additional script handler settings added for framework 3.5 that were causing the errors. We chose jQuery as the backbone of our JavaScript development and only need to have the .ascx web service handler.

As soon as I removed the unwanted handlers, our AJAX calls sprung into life but still none of our AJAX powered controls worked. A quick look with Firebug revealed the reason. All our JSON responses where wrapped in a {d: } object. A little searching on the interweb and the reason was revealed. As a security measure, wrapping the response in that way can stop cross-site scripting attacks.

So why am I annoyed? Well, I cannot fault the reason behind the change, it stops a potentially nasty attack. However, we had no choice in the matter. It broke every one of our AJAX powered controls. Just because Microsoft had handled this change in their own AJAX controls, they decided that nobody else would be using the JSON serializer for anything else. As such, they seem to have no configuration setting to turn it off. We had been running the 2.0 AJAX extension with that vulnerability in it for a while, so I think we should at least be allowed to choose whether we continue that way. Instead, I have to spend hours checking all the JavaScript file for AJAX calls and making them look for their data inside the d object.