Uri uri = new Uri(redirectionUrl);
NameValueCollection col = HttpUtility.ParseQueryString(uri.Query)
uri.Query is already decoded - so is there any way I can prevent ParseQueryString decoding it again?
Apart from that - is there another method to retrieve a name value collection from a Uri without modifying any components?
Encoding the uri.Query before passing it to ParseQueryString is the first thing that comes to my head.
UPDATE
Just checked the ParseQueryString method with Reflector: it assumes that the query string is encoded and you can't do anything with it... Bummer. So I think you need to parse it manually (there are plenty of ready-to-use algorithms on the Web).
Alternatively you could encode your query string properly (taking into account variable names and all special characters) before passing it to ParseQueryString method.
-- Pavel
I have faced the same problem. The solution is adding the second parameter - the encoding. It seams that everything works if you set UTF8 encoding.
NameValueCollection col = HttpUtility.ParseQueryString(uri.Query, Encoding.UTF8)
Related
I'm trying to UrlEncode a web address using Uri.EscapeDataString, but the result isn't correct. Here's an example:
string url = "https://mega.co.nz/#!GVZFwAbB!NzdN2jp7A_WmQBLC4RJrCX8SzixFIEo7oZZARaMAmXQ";
string encodedUrl = Uri.EscapeDataString(url);
Expected result would be:
https%3a%2f%2fmega.co.nz%2f%23!GVZFwAbB!NzdN2jp7A_WmQBLC4RJrCX8SzixFIEo7oZZARaMAmXQ
But the actual one is:
https%253a%252f%252fmega.co.nz%252f%2523%21GVZFwAbB%21NzdN2jp7A_WmQBLC4RJrCX8SzixFIEo7oZZARaMAmXQ
As you can see, there's a bunch of extra %25s that don't belong there. Isn't %25 the encode for "%"? There are no %s in my original string... what's going on?
EDIT: I can't use the System.Web assembly for this project, so unfortunately I can't use the HttpUtility.UrlEncode() method for this.
Well, after searching around a bit more, it seems that this does the job, without relying on system web:
System.Net.WebUtility.UrlEncode(url);
The encoding is the correct one, without %25s.
Uri.EscapeDataString doesn't encode URL. Use HttpUtility.UrlEncode instead.
string url = "https://mega.co.nz/#!GVZFwAbB!NzdN2jp7A_WmQBLC4RJrCX8SzixFIEo7oZZARaMAmXQ";
string encodedUrl = HttpUtility.UrlEncode(url);
Result is:
https%3a%2f%2fmega.co.nz%2f%23!GVZFwAbB!NzdN2jp7A_WmQBLC4RJrCX8SzixFIEo7oZZARaMAmXQ
i have an ashx file that requires some query-string values to deliver appropriate images.
The problem is some search engines urlencode then htmlencode those urls in their cache or when they index those.
So for example instead of getting
/preview.ashx?file=abcd.jpg&root=small
i get
/preview.ashx?file=abcd.jpg&root=small
this basically throws off the context.Request.QueryString["root"] so it thinks that there's no variable root
i guess the second key in the querystring is amp;root i.e the part after the & sign.
What i'm wondering is if there's a way to automatically html and urldecode the querystring on serverside so that the program doesn't get confused.
There is no harm in calling HttpUtility.HtmlDecode or HttpUtility.UrlDecode more than once.
string queryString = "/preview.ashx?file=abcd.jpg&root=small";
var parsedString = HttpUtility.HtmlDecode(queryString);
var root = HttpUtility.ParseQueryString(parsedString)["root"];
To URL encode and decode you can use the following methods:
string encoded = System.Web.HttpUtility.UrlEncode(url);
string decoded = System.Web.HttpUtility.UrlDecode(url);
I've seen instances in the past where the Query String has been doubly encoded. In which case you'll need to doubly decode — this may be your issue...
Assume the following Url:
"http://server/application1/TestFile.aspx?Library=Testing&Filename=Documents & Functions + Properties.docx&Save=true"
I use HttpUtility.UrlEncode() to encode the value of the Filename parameter and I create the following Url:
"http://server/application1/TestFile.aspx?Library=Testing&Filename=Documents%20%26%20Functions%20%2B%20Properties.docx&Save=true"
I send the following (encoded version) of request from a client to a C# Web Application. On the server when I process the request I have a problem. The HttpRequest variable contains the query string partially decoded. That is to say when I try to use or quick watch the following properties of HttpRequest they have the following values.
Property = Value
================
HttpRequest.QueryString = "{Library=Testing&Filename=Documents+&+Functions+++Properties.docx&Save=true}"
HttpRequest.Url = "{http://server/application1/TestFile.aspx?Library=Testing&Filename=Documents & Functions + Properties.docx&Save=true}"
HttpRequest.Url.AbsoluteUri = "http://server/application1/TestFile.aspx?Library=Testing&Filename=Documents%20&%20Functions%20+%20Properties.docx&Save=true"
I have also checked the following properties but all of them have the & value decoded. However all other values remain properly encoded (e.g. space is %20).
HttpRequest.Url.OriginalString
HttpRequest.Url.Query
HttpRequest.Url.PathAndQuery
HttpRequest.RawUrl
There is no way I can read the value of the parameter Filename properly. Am I missing something?
The QueryString property returns a NameValueCollection object that maps the querystring keys to fully-decoded values.
You need to write Request.QueryString["FileName"].
I'm answering this question many years later because I just had this problem and figured out the solution. The problem is that HttpRequest.Url isn't really the value that you gave. HttpRequest.Url is a Uri class and that value is the ToString() value of that class. ToString() for the Uri class decodes the Url. Instead, what you want to use is HttpRequest.Url.OriginalString. That is the encoded version of the URL that you are looking for. Hope this helps some future person having this problem.
What happens when you don't use UrlEncode? You didn't show how exactly you are using the url that you created using UrlEncode, so it is quite possible that things are just being double encoded (lots of the framework will encode the URLs for you automatically).
FWIW I ran into this same problem with RavenDB (version 960). They implement their own HttpRequest object that behaves just like this -- it first decodes just the ampersands (from %26 to &) and then decodes the entire value. I believe this is a bug.
A couple of workarounds to this problem:
Implement your own query string parsing on the server. It's not fun but it is effective.
Double-encode ampersands. First encode just the ampersands in the string, then encode the entire string. (It's an easy solution but not extensible because it puts the burden on the client.)
I am using silverlight / ASP .NET and C#. What if I want to do this from silverlight for instance,
// I have left out the quotes to show you literally what the characters
// are that I want to use
string password = vtakyoj#"5
string encodedPassword = HttpUtility.UrlEncode(encryptedPassword, Encoding.UTF8);
// encoded password now = vtakyoj%23%225
URI uri = new URI("http://www.url.com/page.aspx#password=vtakyoj%23%225");
HttpPage.Window.Navigate(uri);
If I debug and look at the value of uri it shows up as this (we are still inside the silverlight app),
http://www.url.com?password=vtakyoj%23"5
So the %22 has become a quote for some reason.
If I then debug inside the page.aspx code (which of course is ASP .NET) the value of Request["password"] is actually this,
vtakyoj#"5
Which is the original value. How does that work? I would have thought that I would have to go,
HttpUtility.UrlDecode(Request["password"], Encoding.UTF8)
To get the original value.
Hope this makes sense?
Thanks.
First lets start with the UTF8 business. Esentially in this case there isn't any. When a string contains characters with in the standard ASCII character range (as your password does) a UTF8 encoding of that string is identical to a single byte ASCII string.
You start with this:-
vtakyoj#"5
The HttpUtility.UrlEncode somewhat aggressively encodes it to:-
vtakyoj%23%225
Its encoded the # and " however only # has special meaning in a URL. Hence when you view string value of the Uri object in Silverlight you see:-
vtakyoj%23"5
Edit (answering supplementary questions)
How does it know to decode it?
All data in a url must be properly encoded thats part of its being valid Url. Hence the webserver can rightly assume that all data in the query string has been appropriately encoded.
What if I had a real string which had %23 in it?
The correct encoding for "%23" would be "%3723" where %37 is %
Is that a documented feature of Request["Password"] that it decodes it?
Well I dunno, you'd have check the documentation I guess. BTW use Request.QueryString["Password"] the presence of this same indexer directly on Request was for the convenience of porting classic ASP to .NET. It doesn't make any real difference but its better for clarity since its easier to make the distinction between QueryString values and Form values.
if I don't use UFT8 the characters are being filtered out.
Aare you sure that non-ASCII characters may be present in the password? Can you provide an example you current example does not need encoding with UTF-8?
If Request["password"] is to work, you need "http://url.com?password=" + HttpUtility.UrlEncode("abc%$^##"). I.e. you need ? to separate the hostname.
Also the # syntax is username:password#hostname, but it has been disabled in IE7 and above IIRC.
I have an MVC route like this www.example.com/Find?Key= with the Key being a Base64 string. The problem is that the Base64 string sometimes has a trailing equal sign (=) such as:
huhsdfjbsdf2394=
When that happens, for some reason my route doesn't get hit anymore.
What should I do to resolve this?
My route:
routes.MapRoute(
"FindByKeyRoute",
"Find",
new { controller = "Search", action = "FindByKey" }
);
If I have http://www.example.com/Find?Key=bla then it works.
If I have http://www.example.com/Find?Key=bla= then it doesn't work anymore.
Important Addition:
I'm writing against an IIS7 instance that doesn't allow % or similar encoding. That's why I didn't use UrlEncode to begin with.
EDIT: Original suggestion which apparently doesn't work
I'm sure the reason is that it thinks it's a query parameter called Key. Could you make it a parameter, with that part being the value, e.g.
www.example.com/Find?Route=Key=
I expect that would work (as the parser would be looking for an & to start the next parameter) but it's possible it'll confuse things still.
Suggestion which I believe will work
Alternatively, replace "=" in the base64 encoded value with something else on the way out, and re-replace it on the way back in, if you see what I mean. Basically use a different base64 decodabet.
Alternative suggestion which should work
Before adding base64 to the URL:
private static readonly char[] Base64Padding = new char[] { '=' };
...
base64 = base64.TrimEnd(Base64Padding);
Then before calling Convert.FromBase64String() (which is what I assume you're doing) on the inbound request:
// Round up to a multiple of 4 characters.
int paddingLength = (4 - (base64.Length % 4)) % 4;
base64 = base64.PadRight(base64.Length + paddingLength, '=');
IF you're passing data in the URL you should probably URL Encode it which would take care of the trailing =.
http://www.albionresearch.com/misc/urlencode.php
UrlEncode the encrypted (it is encrypted, right?) parameter.
If it is an encrypted string, beware that spaces and the + character will also get in your way.
Ok, so IIS 7 won't allow some special characters as part of your path. However, it would allow them if they were part of the querystring.
It is apparently, possible, to change this with a reg hack, but I wouldn't recommend that.
What I would suggest, then, is to use an alternate token, as suggested by Mr Skeet, or simply do not use it in your path, use it as querystring, where you CAN url encode it.
If it is an encrypted string, you haven't verified that it is or is not, you may in some cases get other 'illegal' characters. Querystring really would be the way to go.
Except your sample shows it as querystring... So what gives? Where did you find an IIS that won't allow standard uri encoding as part of the querystring??
Ok then. Thanks for the update.
RequestFiltering?
I see. Still that mentions double-encoded values that it blocks. Someone created a URL Sequence to deny any request with the '%' characters? At that point you might want to not use the encrypted string at all, but generate a GUID or something else that is guaranteed to not contain special characters, yet is not trivial to guess.