Scott Hanselman

BUG?: Can't use an Asterisk (*) as a character when requesting a URL (page) from ASP.NET

January 26, 2005 Comment on this post [8] Posted in ASP.NET | DasBlog | HttpModule | Bugs
Sponsored By

File this in obscure. I'm trying to fix a bug filed against dasBlog where the guy has a Category in dasBlog called "WS-*"

He filed a bug saying that the CategoryView doesn't work, presumably because it has an asterisk. Now, I KNOW asterisks are allowed in values of querystrings, so this seemed weird to me.

Turns out he's using the UrlRewriting feature of DasBlog so he gets URLs like this:

http://localhost/DasBlog/CategoryView,category,WS-*.aspx

The idea is to fool search engines into thinking there are actual pages, instead of one page with an URL like:

http://localhost/DasBlog/CategoryView.aspx?category=WS-*

Here's where it gets weird. We use a thing called the UrlMappingModule to catch ALL requests (all the requests that are handled by ASP.NET) and then call app.Context.RewritePath(newPath) which routes, in this case, the request to CategoryView.

However, if an asterisk (*) appears anywhere IN THE (purported) FILENAME, ala CategoryView,category,WS-*.aspx then ASP.NET never hears about it, the HttpModule's BeginRequest never fires and I can't do crap about it. All I see is an HTTP 400 Bad Request.

So, without digging further, I can only assume that the ASPNET_ISAPI extension didn't think it was cool to pass the request on. Of course, when the * appears as a value int the QueryString, everything is cool.

What other component/filter/module upstream might be slapping this request down? I'm not running any thing special on this development box.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
January 26, 2005 11:48
Cool. Thanks, Scott

"The guy" in your post will just rename his category from WS-* to WS-Splat ;-) No probs. However, the renaming portion is still a rather relative manual affair. Without touching on the content files, I need to re-assign all posts from WS-* to WS-Splat one-by-one manually.

Maybe this could be a new improved feature in 1.8 ? ;-)

Thanks a lot, Scott
January 26, 2005 12:03
Why not just FindInFiles and change the XML directly?
January 26, 2005 18:02
I'd take a guess here and say that IIS is probably rejecting the request because it does not refer to a valid file name, BUT ... If you try something like otherFile*.html you should get 404 Fil Not found, which tells me IIS actually tried to process the request without rejecting it. The same happens for someThingElse*.asp.
Only files with an asterisk and .aspx extensions showed this behavior for me, which leads me into thinking ASPNET_ISAPI is trying to do something else other than serving the file. This was even more interesting on my local box, where IE popped-up a user/password/domain dialog (for which even the local admin credentials failed), possibly indicating it was trying to perform a "DIR" or something like it...
I have nothing to support all this guessing, though.
January 26, 2005 22:18
Any possibility that maybe the machine has been locked down and that URLScan is rejecting the character?
January 26, 2005 22:20
I agree with Sergio - I only get the bad request for .aspx or .asmx extensions on the IIS5.0 and IIS5.1 boxes I tried it on. Both have .NET 1.1 installed. I tried using "*" with several other extensions and get 404. There's a KB article I found that might explain the wierd behavior:

FIX: "HTTP 400 - Bad request" error message in the .NET Framework 1.1
http://support.microsoft.com/default.aspx?scid=kb;EN-US;826437

All of the characters mentioned in the KB article (* % &) also give me a 400 error if URLScan is not installed. If URLScan is installed, it may block some of those characters (such as %) and give you a 404 error.
January 26, 2005 22:28
Aaron - No, I'm running this locally with no filters or UrlScan or anything in the way (that I can see).

Kevin - That article is definitely it. I can feel it. ;) Thanks for finding that.

My conclusion is that I'm not that interested in fixing this that I'm going to install a HotFix or messed with any "compatibility" flags.
January 27, 2005 0:45
That KB is exactly it. I tried on .NET 1.0 box and got the login pop-up I mentioned above. Then I switched the .Net version of the app to v1.1 and got the bad request message. Because this issue also manifests itself with the "%" character, it doesn't seem possible to escape the "*" or ":"... I guess dasBlog will have to validate all the user entered data that is used in re-written url paths to disallow those characters for now.
January 28, 2005 8:17
No problem - glad I could help. I agree, any KB fix that requires me to contact Microsoft to get the patch has to be very very important for it to be worthwhile.

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.