Something just seems wrong when it is possible to specify web paths that will fool the parser. This seems inherently insecure. I don't disagree with your comments to keep paths short and clean but to be worried that specifying a directory with .com is going to fool the parser just makes me wonder about either the URL/HTTP specifications or the implementation of IIS.
Microsoft has spent lots of effort allowing users to have long file names and directory names. I rememeber the old 8.3 days and I for one love good descriptive names - though I hate blanks in names like "Program Files" and needless dots (.) are kinda silly too - yet .Net actually encouraged this practice.Your advise is good but the Microsoft examples out there contradict them.
I appreciate your concern here, however, the thing to keep in mind is that the parser is not fooled, it is simply parsing according to its rules. Keep in mind that you cannot send this kind of URL from IE as it wil not allow it. You have to use another utility of some kind. See http://www.windowsitpro.com/Article/ArticleID/23278/23278.html?Ad=1http://www.mvps.org/marksxp/WindowsXP/IIS/iis4.phpAnd Writing Secure Code by Michael Howard"Just say no to parent paths. If you remove the requirement for parent paths in your application, anyone attempting to access a resource by using parent paths is, by definition, an attacker!"http://www.microsoft.com/mspress/books/sampchap/5612b.asp