ASP.NET 400 Bad Request with restricted characters

Today I had to hunt down a reported defect that said our advanced search functionality was returning a Bad Request error. On initial inspection, I was unable to reproduce the issue. After talking to our product manager, I learned that he was trying to seed the search with the text “% %”. We have a quick search text box that lets you enter your criteria, and it has some built in rules about which fields it applies the criteria to. If you need more control over the criteria, you can enable the advanced search, and your quick search criteria will automatically be populated in the advanced search page. The way we were doing that was by passing the criteria in the URL, as in: http://localhost/dovetailcrm/contacts/query/yourbasiccriteria.

To seed the advanced search for “% %’, it would load http://localhost/dovetailcrm/contacts/query/%25%20%25 (% URI encodes as %25, space encodes as %20)

We were properly encoding the request, so what the problem? Attempting to load that URL would cause the error:

400 Bad Request
ASP.NET detected invalid characters in the URL.

Proceed at your own risk

My first instinct was to suspect URLScan, or the IIS 7.0 equivalent. After a bit of googling, it became apparent that ASP.NET really didn’t like it when you tried to pass 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 characters in your URL”.

That didn’t sit well with me – it didn’t seem right that there was no way to pass those characters in the URL without having to change your server configuration which could potentially expose your site to security risks.

Just because you can, doesn’t mean you should

After a little bit of experimentation, I discovered that you certainly CAN pass those characters in a URL: they just have to be passed in the query string (the part after the question mark). It suddenly started to make sense why there was not a whole lot of information on this error, and why the little information that was available seemed to be related to ASP.NET MVC. Up until ASP.NET MVC (or more accurately, System.Web.Routing), you would almost always send parameterized data in the URL as part of the query string. It wasn’t until we got Routing that we started putting parameters in the path portion of the URL.

So after making a short story long, the solution was to simply pass the information the old fashioned way, in the query string: http://localhost/dovetailcrm/contacts/query?search=%25%20%25

Related Articles:

This entry was posted in mvc. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • benb

    to me this is a bug. It is one I submitted last year for MVC and never has been resolved. The problem is, when one is trying to make a RESTful service (as an example), ALL valid characters as defined by the standard should be acceptable.

    What I found is, basically any character that is not valid for a Windows file name causes this issue. With routing, this is a bug. Given we are not looking for a specific disk file, all protocol standard characters should be considered valid. When looking at something like the Yahoo! Boss API, with MVC or anything on ASP .NET, you would not be able to pass in the query in the same way? Why? This is not correct as it does not work the way it should and the way the standards say it should.

  • Ben

    Totally agree with benb’s assesment.

    We use custom URL rewriting in asp.net 2.0 (not MVC routing) precisely so we don’t have to use ugly URLs like :

    http://localhost/dovetailcrm/contacts/query?search=%25%20%25

    This is a bug. For us a really really annoying one.

  • http://www.lostechies.com/members/jflanagan/default.aspx Joshua Flanagan

    First, whether its a bug or not doesn’t really matter to me. I’m merely providing info on 2 different ways to deal with it (by changing the framework behavior, or working around it).
    Second, its hard to call it a bug with MVC, since none of the MVC code is causing the problem – its in the underlying ASP.NET layer.
    Third, I think I’d classify it as “default behavior that you disagree with”. The framework was designed to operate in 2 modes “allow those characters in the path”, or “dont allow those characters in the path”, with documented ways to change the mode. They chose “dont allow” as the default mode, but you can change it if you disagree (by following the KB articles linked in the Dirk.Net post mentioned above).
    Fourth, yes its really annoying!

  • http://vijay.screamingpens.com Vijay Santhanam

    This feature is rather annoying. Wish there was more info about this issue by MS. Explaining why, and maybe a turn off feature if need be.

    Also, a replacement string formatter would be nice

  • Tom Scarr

    I’m having a similar issue with the ‘ASP.Net 400 Bad request with restricted characters’ issue when hosting with IIS7. I am base 64 encoding some of the parameters. I cannot see any problematic characters such as ampersands etc in the following url:

    http://localhost/Revolution/PrintingWm/PrintPageAsPdf/1/UGVyZm9ybWFuY2UgT3ZlcnZpZXcgLSA1WSBFcXVpdHk/eyJhbmFseXNpc0V4ZWN1dGlvbklkIjoic2hhcnJpczsyODNkZjQxOC03MDgxLTQ2MWQtODEwYi1lMzU1ZTYzNjk4NGEiLCJwZXJpb2RDb2RlIjoiRWFybGllc3QiLCJzdGF0aXN0aWNzTWVhc3VyZUxheW91dElkIjoiMzIiLCJiYXJDaGFydE1lYXN1cmVMYXlvdXRJZCI6IjYwIiwibnVtYmVyT2ZMb3dWYWx1ZXMiOjUsIm51bWJlck9mSGlnaFZhbHVlcyI6NX0=

    Can anyone suggest whether there are problematic characters here that would cause ASP.Net to be unhappy? I may end up resorting to query strings as that seems to work. But I’m still confused as to why this Url would not be accepted.