I am using HttpUtility.UrlPathEncode for encode url. when hit encoded url result is page not found
HttpUtility.UrlPathEncode("http://example.com/Fundamentals of Data Structures C++")
Encoded Url
http://example.com/Fundamentals%20Of%20Data%20Structures%20C++
Page not found
Please help me to resolve this issue
The + sign is a special sign in URLs. It's used to represent a space. You should Encode the + sign. It's value should be %2B. E.g. HttpUtility.UrlPathEncode(someURL).Replace("+","%2B")
Related
Trying to understand why pasting the first link works but not the second one.
Breakdown of the URL, for a clearer view:
Encoded version: [works]
http%3A%2F%2FsomeSite.com
%2FDownload.ashx
%3Frequest
%3DIL7zxW6ETqiYU6cThSNKL8MpY
%252bCRIVFZAVhd8DYPG85C1Uhdd
%252f2hqqmoObeNmuS3dg4bDgGBb0kUUxGZhej89kTaLBHBXS
%252bq3tlaEk2uMEcbWlUZzZQs00sirwZ2IvAvoSpU7HC3N1FaYSNciQ4iHNNmTU
%252f6uMypNlPOJ6enlbZ1OrrYODkaMRdRfGKEba
%252brusdryM4gp
%252bopi1a0gNuMQVCtj
%252bAvDcgXGOcZPNhPAnE
%253d&version=Ma88r6Z6t2JQcnVhVXgp0A%3D%3D
Decoded version: [doesn't work]
http://someSite.com
/Download.ashx
?request=
IL7zxW6ETqiYU6cThSNKL8MpY
+CRIVFZAVhd8DYPG85C1Uhdd
/2hqqmoObeNmuS3dg4bDgGBb0kUUxGZhej89kTaLBHBXS
+q3tlaEk2uMEcbWlUZzZQs00sirwZ2IvAvoSpU7HC3N1FaYSNciQ4iHNNmTU
/6uMypNlPOJ6enlbZ1OrrYODkaMRdRfGKEba
+rusdryM4gp
+opi1a0gNuMQVCtj
+AvDcgXGOcZPNhPAnE
=&version=Ma88r6Z6t2JQcnVhVXgp0A==
If I paste the first link in the browser - it works. A file download automatically starts.
If I paste the second link in the browser - page says Bad request.
Can anyone clarify it for me why the second one doesn't work?
Quoting the URLencodetag:
To “URL encode” or “percent encode” text means to encode it for use in a URL. Some characters are not valid when used as-is in URLs, and so much be URL-encoded (percent-encoded) when appearing in URLs.
The encoding was used for a reason, here because the base64 values for the request and version parameters contains +, / and = which have their own meaning in URLs and therefore need to be URL-encoded.
My server logs show a many attempts to access non existing sides. These are the "usual" bots scanning for known vulnerabilities. Many of the URLs contain =3D, e.g.
/?q=3Duser%2Fpassword&name%5B%23p=
/user/register/?element_parents=3Daccou=
/wp-admin/admin-post.php?swp_debug=3Dlo=
%3D is the url encoded value of = so I would expect to find %3D within the URL but not =3D. However, =3D can be found all over the logs. What is the meaning of this?
=3D is an example of a Quoted-Printable encoding for ASCII 0x3D, or the equals sign character (=).
You don't usually see this in URLs. It's not the normal encoding to use. It's a standard MIME type, an alternative to using base64. It looks like the request is expecting the app to decode the query string using Quoted-Printable, and then use the resulting path in some further redirect.
My URL is
www.domainname.com/default.aspx?l=en&t=32600483-1618-4f09-9a86-c12de4dafc7b
I would love to read the QueryString value of t. So i can parse it as GUID.
Unfortunatelly that & thing, seems to mess things up.
How can i parse the value of the t Query string?
My URL is
I hope you realize that this is not a valid URL. This is a HTML encoded string. Do not confuse with an URL. URLs should be properly URL encoded, not HTML encoded. And since you start with something invalid your only chance is to use some ugly string parsing/regex to extract the necessary information. Since this looks like an HTML encoded string you could HTML decode it first:
var myUrl = "http://www.domainname.com/default.aspx?l=en&t=32600483-1618-4f09-9a86-c12de4dafc7b";
myUrl = HttpUtility.HtmlDecode(myUrl);
var values = HttpUtility.ParseQueryString(myUrl);
var t = values["t"];
But I repeat once again: don't do this: tackle the problem at its root. And the root of your problem is the origin of this URL. So if you have control over the generation of this URL then fix it so that you can have a valid URL that you could easily work with with the built-in methods. If you don't have control over the generation of the URL then notify the author of the code that he has a bug in it and ask him to fix it because he has provided you a non-properly encoded URL and you are obliged to use some ugly string parsing mechanisms to extract the information from it.
I have an encrypted query string passed from another page, it reads something like "/se73j+sef" but after receiving it, the '+' sign got omitted and became "/se73j sef". Is this normal? Please kindly advice. Thanks.
Is this normal?
Yes, perfectly normal. + is a special character in an url. It means space (0x20 ASCII character). If you want to represent the + sign you will have to url encode it:
/se73j%2Bsef
To url encode a string in .NET you could use the UrlEncode method. Or depending on how you are building the url there are certainly better ways.
I am using the Google QR-Code API to create a QR-Code that includes a URL. This is the URL I am using:
https://chart.googleapis.com/chart?chs=500x500&cht=qr&chl=http://www.test.de/Web/Portale/Form.aspx?PortalId=1&FormName=DetailsForm1&EstateId=14490
What I want in the QR-Code is:
http://www.test.de/Web/Portale/Form.aspx?PortalId=1&FormName=DetailsForm1&EstateId=14490
What I get is:
http://www.test.de/Web/Portale/Form.aspx?PortalId=1
So its cutting at the "&". Any ideas how to solve that?
Thanks :-)
You have to escape for your URL part before parsing into chl parameter.
A simple way would be replacing & with %26 for your url portion.
Try this instead: https://chart.googleapis.com/chart?chs=500x500&cht=qr&chl=http://www.test.de/Web/Portale/Form.aspx%3FPortalId=1%26FormName=DetailsForm1%26EstateId=14490
You need to URL encode the value of the chl parameter. Otherwise the & in that embedded URL will be interpretted as a delimiter for the parameters in the querystring of the outer googleapis.com URL.
If you are using Javascript you can use encodeURIComponent('http://www.test.de/Web/Portale/Form.aspx?PortalId=1&FormName=DetailsForm1&EstateId=14490') to do the encoding.
Solved this, the solution was to use the following code:
Server.UrlEncode(string url)
Now it works perfectly :).
Thanks, encoding was what made it click for me :).