开发者

Using Url.RouteUrl to Redirect to URL with #, %, and so on

开发者 https://www.devze.com 2022-12-08 06:14 出处:网络
In a web application I\'m working on, we\'d like to be able to show information about resources at a given path.The path is entirely virtual—it only exists in the application—so we don\'t

In a web application I'm working on, we'd like to be able to show information about resources at a given path. The path is entirely virtual—it only exists in the application—so we don't really have a problem with users setting virtual paths that are "weird" by normal file system standards.

The issue: we have a route that reads something similar to

/Files/{*path}

and we attempt to redirect with

Url.RouteUrl("File", new { path = somePath })

This usually works, but fails if somePath contains & or #, among others. In those cases, I'm suck. I can't UrlEncode(somePath) at this point, because RouteUrl does its own URL encoding, but I can't leave them as-is, because otherwise they're treated improperly (the octothorp doesn't get passed to the routing data, and the ampersand confuses IIS). Is there a sane way around this? Or do I basically just need to implement my own routes via stri开发者_运维百科ng interpolation?


I've been playing around with your example, and I cannot find any problems with using RouteUrl with special characters as you describe above, at least not in my test environments. The RouteUrl method encodese the urls correctly, and the controller gets the value in decoded form without any problems or deformities.

I've tested this out in IIS 7 as well as the VS 2008 development web server.

Can you provide more complete sample code?


The best answer I've found so far, though it only works on IIS7, is to follow the instructions at http://dirk.net/2008/06/09/ampersand-the-request-url-in-iis7/ to edit the registry and change some of IIS7's default behavior. This is unacceptable for us, since we're making an application that will be installed on end user's machines—and at any rate, even if we weren't, there'd be the simple fact that IIS6 and IIS5 don't respond to this sequence. Any ideas for earlier versions of IIS, or ways to override this behavior programmatically in IIS7, would be wonderful.

0

精彩评论

暂无评论...
验证码 换一张
取 消