Ampersand & the Request URL in IIS7

ASP.NET MVC, IIS7 Add comments

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, here comes the more pleasing

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
  2. Interestingly enough, enable VerificationCompatibility (;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.

[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

23 Responses to “Ampersand & the Request URL in IIS7”

  1. Abel Haslett Says:

    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!

  2. Lee Kelleher Says:

    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!

  3. ASP.NET 400 Bad Request with restricted characters - Joshua Flanagan - Says:

    [...] a %, &, *, or : in the URL. The various fixes were scattered around different forum posts, but summed up nicely at Dirk.Net. Unfortunately, the only answer seemed to be “make a registry change” or “don’t pass those [...]

  4. Andy Says:


  5. * % & : Special Characters in URL and files causing HTTP 400 Bad Request | Rizo's Says:

    [...] Finally, the solution was found @ with an article regarding 400 bad request in IIS7 (But IIS6 also has the same problem and the solution will work there too). You can read about it here. [...]

  6. aewfjoiaewf Says:

    Doesn’t seem to work for IIS7.5, sadly. Any ideas?

  7. aewfjoiaewf Says:

    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

  8. Jeff Paetkau Says:

    I still get “Bad Request” if I add UrlRoutingModule to
    <add name=”UrlRoutingModule” …

    If I remove that line it works. Any help appreciated …

  9. Patrick Rietveld Says:

    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’.

  10. dirk Says:

    @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!

  11. Saurabh Maurya Says:

    Enabling VerificationCompatibility worked for me.
    Below is link for more info;EN-US;826437

  12. Daniel Says:

    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 :(

  13. Craig Says:

    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:

  14. Bill Says:

    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).

  15. Bill Says:

    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:

    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:

    … 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.

  16. Bill Says:

    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.

  17. dirk Says:

    @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.

  18. IIS 7 “bad request” Drija Says:

    [...] Tom Harvey Solved using this: September 2, 2009 2:40 am zasyatkin I also solved this using that same sites [...]

  19. ali Says:

    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

  20. bill Says:

    And still a useful post all these years later!

  21. IIS 7 “bad request” - Just just easy answers Says:

    [...] Solved using this: [...]

  22. Allow (and correct the URL) when there is a special character such as using IIS and the rewrite module - FAQs System Says:

    [...] tried to ignore them using multiple methods, but nothing seems to [...]

  23. Allow (and correct the URL) when there is a special character such as using IIS and the rewrite module | Question and Answer Says:

    [...] tried to ignore them using multiple methods, but nothing seems to [...]

Leave a Reply