views:

18

answers:

1

My WebApp is part CMS, and when I serve up an HTML page to the user it typically contains relative paths in a.href and img.src attributes.

I currently have them accessed by urls like: ~/get-data.aspx/instance/user/page.html -- where instance indicates the particular instance for the report and "user/page.html" is a path created by an external application that generates the content.

This works pretty reliably with code in the application's BeginRequest method that translates the text after ".aspx" into a query string, then uses Context.RewritePath().

So far so good, but I've just tripped over something that took me by surprise: it appears that if any of the query string ("instance/user/page.html") happens to contain a plus sign ("+") the BeginRequest method is never called, and a 404 is immediately returned to the user.

So my question is two-fold:

  1. Am I correct in my belief that a "+" would cause the 404, and if so are there other things that could cause similar problems? Is there a way around that problem (perhaps a different method than BeginRequest)?

  2. Is there a better way to preserve relative URL paths for generated content than what I'm using? I'd rather not require site admins to install a 3rd party rewrite tool if I can help it.

A: 

Yes this is an IIS security setting. You can get round it by putting this in your web config.

<system.webServer>
<security>
    <requestFiltering allowDoubleEscaping="True"/>
</security>
</system.webServer>

However youmight have to be carefull what you are doing. With double escaping enabled it will allow an escaped url to itself contain escape characters that could be used to exploit your url rewriting to pass escaped characters into your querystring to construct a different querystring than you intend.

Ben Robinson
Thanks, I can live with this for now, but I don't want *double* escaping, I really want it _unescaped_ -- I want the characters (**+**, et al) passed through unchanged. This converts them to a space instead.I understand about double-escaped characters (like **%2526**) but in my case I'm not worried about exploits.
NVRAM
Actually, **Request.RawUrl** has the *+* still, but *%XX* is decoded (*%2F* becomes a slash, etc.)
NVRAM