Dirk Bergmann

Developer, panographer. Does consultancy work from own company. Lives in Chiang Mai, Thailand.

Twitter

Chiang Mai

Hua Hin

Thailand Hotels

ListVote - List. Vote. Learn.

Partnerseek - Find Partners

Ampersand & the Request URL in IIS7

Update: The below ?solution? should not be considered as it creates invalid URLs. All ampersands should be encoded as "%26", see Bill's comments from Nov. 11, 2010. This was just meant as a quick-fix-short-term-workaround as these URLs were supported in IIS 6. There's a reason why IIS 7 and above don't support them.

With the arrival of ASP.NET MVC and the complementary IIS7 file-extension-less request pipeline it's finally possible to turn ugly "classic ASP.NET" query string URLs into pretty and orderly REST-style URLs, functionality that PHP had for ages. Out with _http://mysite.com/catalog.aspx?category=1&product=100_, here comes the more pleasing _http://mysite.com/widgets&gadgets/the-useful-&-beautiful-widget_

However, the ampersand in the latter will generate a "400 Bad Request" response with the default settings in IIS 7 because the ampersand (&) is not acceptable in the request for security reasons. As discussed here, it takes two measures to fix this and make the URL (I did not have to take the third measure quoted in the post, which is setting ValidateRequest="false" in the ASP.NET MVC view page):

  1. AllowRestrictedChars http://support.microsoft.com/kb/820129
  2. Interestingly enough, enable VerificationCompatibility (http://support.microsoft.com/default.aspx?scid=kb;EN-US;826437), a measure designed for pre-SP1 ASP.NET 1.1, but necessary here even with ASP.NET 3.5 to get the ampersand URLs working.

Hope it helps.

#

Abel Haslett: You my man, are a legend! Thank you so much for this post. I had searched for ages in Google for a solution to my ampersand problem that occurred after updating the latest service packs, and now it is resolved!

aewfjoiaewf: Found the solution. Problem is that I'm running 64 bit Windows but 32 bit IIS, so the registry entries are in a different location. The only change I needed to make was at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ASP.NET. Added DWORD VerificationCompatibility = 1

Andy: Thanks!

dirk: @Patrick: Not sure if they're actually a security risk, but you're absolutely right that ampersands don't belong in an URL and should be avoided or encoded. Google doesn't like them either. Thanks for your comment!

Lee Kelleher: Thanks Dirk! I've just ran into this ampersand 400-error problem for the first time. Luckily, I found your post and quickly fixed it! I did see the posts on the ASP.NET forums, but it's nice to read a condensed, "do this, it works" blog post, thanks!

Daniel: This just doesn't seem to be doing the trick for me :( Server 2008 R2 x64 , after applying changes and reboot, still no luck with & in URLs, and 400 :(

aewfjoiaewf: Doesn't seem to work for IIS7.5, sadly. Any ideas?

Patrick Rietveld: It seems to be a solution for the ampersand problem. But it's not. This will introduce a security risk, and that's a far more bigger problem to me. The only solution is 'do not ampersands in file and folder names'.

Saurabh Maurya: Enabling VerificationCompatibility worked for me. Below is link for more info http://support.microsoft.com/default.aspx?scid=kb;EN-US;826437

Jeff Paetkau: I still get "Bad Request" if I add UrlRoutingModule to <add name="UrlRoutingModule" ... If I remove that line it works. Any help appreciated ...

dirk: @Bill: Thanks, I have updated the post. At the time I had quite a few pages indexed in Google with the ampersand in them and in a competitive market the url might just look a little more attractive for the search user than the encoded one. As of now, Google still indexes pages with the incorrect ampersand in them and they don't seem to get penalized much.

Craig: Hi Daniel, I have same server as you 2008 R2 x64 and was able to get this to work. Did you make the two registry changes? Reference this link below for the two registry additions you need to make: http://kb.cadzow.com.au:15384/Cadzow/details.aspx?ID=2270

Bill: Holy crap, this is a seriously bad idea. As noted above by both Dirk and Patrick, ampersands do NOT belong in the URL un-encoded like that. By enabling "AllowRestrictedChars", you're making it possible to create working URLs on your server that won't be supported by anything else. So Google, very likely, won't get to that page. Or various browsers. It's all undefined as to what anything will do. The solution to the problem should NOT be what's suggested above, and this needs to be clearer. It should be enabling some way of making IIS encode the ampersand character as HTML entities (or dropping them all together if you're really trying to make it aesthetically pleasing and don't want "&" in your URL).

Bill: Just to clarify, with the above solution, correct me if I'm wrong but it means that the working URL for that hypothetical page will be: http://mysite.com/widgets&gadgets/the-useful-&-beautiful-widget Which is an invalid URL, and invalid HTML. And yet that's the only way to get to the page. Meanwhile, the "correct" version of that URL: http://mysite.com/widgets&gadgets/the-useful-&-beautiful-widget ... will fail and will not return the page in question. I'm seeing this on a web site right now which appears to have applied this method.

Bill: Sorry for a third post, but I'm just seeing that this comment form is not escaping HTML entities either and so the above examples don't read correctly. Ampersand characters in the URL, in the folder and filename part should only ever appear as "%26" Ampersand characters in the URL, after the filename as HTTP GET parameters, should only ever appear in HTML as "& amp ;" (without the spaces) The above "solution" renders both of these correct URLs invalid, while the only way to get to the page is to use an invalid URL. This is going to fail with alot of things on the web.

ali: Thanks for this solution. Is there any solution for same problem on apache shared server. I have similar issue on my wp website but that is on apache

bill: And still a useful post all these years later!