可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
I'm trying to create something similar to the diggbar.
I'm using Visual Studio 2010 and Asp Development server.
However, I can't get the ASP dev server to handle the request because it contains "http:" in the path. I've tried to create an HTTPModule to rewrite the URL in the BeginRequest , but the event handler doesn't get called when the url is http://localhost:5957/http://yahoo.com. The event handler does get called if the url is http://localhost:5957/http/yahoo.com
To summarize:
- http://localhost:5957/http/yahoo.com works
- http://localhost:5957/http//yahoo.com does not work
- http://localhost:5957/http://yahoo.com does not work
- http://localhost:5957/http:/yahoo.com does not work
Any ideas?
回答1:
I've written an article with Stefan's help that explains how to do this:
Experiments in Wackiness: Allowing percents, angle-brackets, and other naughty things in the ASP.NET/IIS Request URL
回答2:
From Stefan on the ASP.Net team: http://forums.asp.net/p/1431148/3221542.aspx
In current versions of ASP.NET Urls containing characters like the colon character will be rejected as a potential security threat. The historical reason for this is that the underlying NTFS file system supports alternate resource streams that can be accessed with names like "yourfile.txt:hiddendata.txt". Blocking the colon character from Urls prevents poorly written applications from accidentally working with alternate resource streams.
There is also a limitation in current versions of ASP.NET that incoming Urls need to map to the NTFS file system for purposes of determining managed configuration data.
In ASP.NET 4 these limitations can be optionally removed. However these changes are in the Beta 2 version of ASP.NET 4 - they are not in Beta 1. We tried out the Url listed earlier in this forum post and confirmed that with our internal builds of ASP.NET 4 you can use that style of Url and process it without any 400 error.
-Stefan
回答3:
From Stefan on the ASP.Net team
I snipped the following from a forthcoming What's New document covering Beta 2:
ASP.NET 4 introduces new options for expanding the range of allowable application Urls. The simplest and most useful change is that ASP.NET gives developers the option to allow longer Urls. Previous versions constrained Url path lengths to 260 characters (the NTFS file path limit). In ASP.NET 4 developers have the option of increasing (or decreasing if they choose) this limit as appropriate for their applications using two new httpRuntime configuration attributes:
Modify the value for "maxRequestPathLength" to allow longer or shorter Url paths (the portion of the Url sans protocol, server and query-string). Modify the value for "maxQueryStringLength" to allow longer or shorter query strings.ASP.NET 4 also enables developers to adjust the set of characters used by ASP.NET's Url character checks. When ASP.NET finds an invalid character in the path portion of a Url it rejects the request with an HTTP 400 error. In previous versions the Url character checks were limited to a fixed set of characters. In ASP.NET 4 developers can customize the set of character checks using another new httpRuntime configuration attribute:
By default the "requestPathInvalidChars" attribute contains seven characters considered invalid (the less than and greater than signs as well as the ampersand are encoded since configuration is an Xml file). Developers can then expand or reduce the set of invalid characters as appropriate for their application's needs. Note that ASP.NET 4 will still reject any Url paths that contain characters in the ASCII character range of 0x00-0x1F since those are considered invalid Url characters (RFC 2396 considers these characters invalid, and on Windows Servers running IIS6 or higher the http.sys protocol device driver automatically rejects Urls with these characters as well).
回答4:
I've had exactly this problem in creating a URL shortener for ASP.net. For the life of me, I could not get the colon encoded in such a way that ASP would accept it, using either HttpUtility.UrlEncode or javascript's escape() on the client-side.
My solution what to do Base64 encoding. Turns the whole thing into non-controversial alpha-numerics. Then you decode on the server. I used these functions.
Also, I created an HttpModule to be triggered by a leading hyphen so I know to handle what follows as a URL to be decoded. Ping me if you want further details.
回答5:
You need to use HttpUtility.UrlEncode on your string before redirecting to it.
回答6:
I'm not sure what web server digg is using but I'm betting this simply isn't possible with IIS or the built in web server for VS. Most likely it's a web server that can be modified to allow all sorts of wacky URLs.
回答7:
This isn't IIS failing, its the ASP Development server. Try deploying to IIS and see if it works.
回答8:
I'm pretty sure you could do it with IIS rewrite. ASP.NET Development Server can't do rewrite as far as I know but you could try doing it by using either IIS7 rewriter or if you have an earlier version, by the Ionics ISAPI Rewrite Filter.
回答9:
The KB article 826437 ( http://support.microsoft.com/kb/826437 ) contains an answer to your question
- Ensure Microsoft .NET 1.1 SP1 is installed on the machine
- In the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET
create a 32bit DWORD value of VerificationCompatibility = 1
- Restart IIS.
It worked for me (IIS 6, ASP.NET 4), probably it will work for you, too
回答10:
A quick solution for development environment:
Change Web project properties to "Use IIS Local Server" and check "Use IIS Express" (which preserves the URL of VS Dev Server).
Add the following setting in Web.config inside <system.web>
:
<httpRuntime requestPathInvalidCharacters="" />
For production deployment, take into account the security considerations mentioned in other answers.
回答11:
I answered a similar question here.
https://stackoverflow.com/a/12037000/134761
Basically, ASP.net only accepts encoded characters such as colon after the question mark. Fortunately ASP.net MVC automatically maps both /api/persons/xxxx and /api/persons?id=xxxx equally in the default mapping, so that is what I ended up doing.
回答12:
Try HttpUtility.UrlPathEncode(url)
- MSDN Docs