This project has moved and is read-only. For the latest updates, please go here.

OwinHttpListener Bypasses HttpListener unescapeRequestUrl Setting

Dec 3, 2013 at 1:40 AM

I've been trying to use URL-encoded forward slashes in URL's. HttpListener supports this via an app.config setting, but the setting had no effect on a self-hosted Owin app.

Digging in to OwinHttpListener.cs, I see that it's accessing the HttpListenerRequest's private m_CookedUrlPath field via reflection and using that to build the request path. That field takes the raw value from HTTP.sys and ignores the processing HttpListenerRequestUriBuilder does, such as passing encoded values through.

Is there a reason that the cooked URL is be accessed directly rather than through standard properties? It seems accessing private fields by reflection is something to be avoided in general, but in this case it's specifically disabling needed functionality.
Dec 3, 2013 at 8:06 PM

This change was made because the public fields did not provide the correct un/escaping in several scenarios. Yes, we rely on Http.Sys to canonicalize the URL, some of which can be controlled via the registry.

I don't think we have a workaround for your encoded forward slash scenario.
Dec 3, 2013 at 9:29 PM
Edited Dec 3, 2013 at 9:29 PM
I don't suppose you have any record of those problem scenarios? It would be valuable to know what we're walking in to should we decide to use the public fields.
Dec 3, 2013 at 10:22 PM
Looking at my notes, the request uri property would do lots of extra un/escaping around dots, slashes, etc.. The raw URI was primarily unsafe due to the lack of canonicalization (compressing ..\ segments, etc.). The unit tests linked above cover the full range of characters and how they're handled.
Dec 4, 2013 at 1:55 AM
Thank you very much for you responses. I love what you and your team are doing here. Keep up the good work!
Feb 20, 2014 at 12:15 PM
Edited Feb 20, 2014 at 12:20 PM

I've basically the same problem as Jaecen.
Thus I wanted to ask if you could confirm that there is no way an URL like'1%2F3812')/
gets routed correctly (i.e. forward slashes and dots cannot be used in an escaped form)?

If so, are there any plans to "fix" this issue?
Feb 20, 2014 at 11:04 PM
I don't think that's currently possible. There are no open issues for this. If this is blocking you please open an issue for it.
Feb 21, 2014 at 6:56 AM
Thanks a lot for the quick support, I created an issue