What does the symbol ? mean in a URL?
That portion of the URL (ie. after the ?) is known as the query string.
http://en.wikipedia.org/wiki/Query_string
It is used to pass parameters into web applications.
For example, in ASP.NET I might have an .aspx page like so:
http://example.com/myapp/default.aspx
Inside my codebehind for that page I can look for the presence of any query string parameters:
string paramValue = Request.QueryString["param"];
So if someone visits my page with the URL of http://example.com/myapp/default.aspx?param=abcd
Then the value of paramValue will be "abcd".
RFC for http protocol, section 3.2.2 http URL
"?" - is delimiter between "absolute path" and "query"
Related
I have a base url that i want to redirect the user to, but this url have another url in its query param
for ex:
base_url = "https://www.base.com?origin=#{origin_url}"
the origin url itself have some query params
origin_url = 'https://www.origin.com?utm_source=foo&utm_term=bar'
but there is a problem with that, if I just use this url it comes like this
https://www.base.com?origin=https://www.origin.com?utm_source=foo&utm_term=bar
with that url, the &utm_term becomes a query string for the base url, and not for the origin url
is there a special type of encoding to deal with this nested query string problem ?
I've tired use URI.encode_www_form_component in the origin_url, and I got
https%3A%2F%2Fwww.origin.com%3Futm_source%3Dfoo%26utm_term%3Dbar
so the Full url became
https://www.base.com?origin=https%3A%2F%2Fwww.origin.com%3Futm_source%3Dfoo%26utm_term%3Dbar
but the problem is that I always decode the url before redirect, so it just get decoded again.
Just say I have the following url that has a query string parameter that's an url:
http://www.someSite.com?next=http://www.anotherSite.com?test=1&test=2
Should I url encode the next parameter? If I do, who's responsible for decoding it - the web browser, or my web app?
The reason I ask is I see lots of big sites that do things like the following
http://www.someSite.com?next=http://www.anotherSite.com/another/url
In the above, they don't bother encoding the next parameter because I'm guessing, they know it doesn't have any query string parameters itself. Is this ok to do if my next url doesn't include any query string parameters as well?
RFC 2396 sec. 2.2 says that you should URL-encode those symbols anywhere where they're not used for their explicit meanings; i.e. you should always form targetUrl + '?next=' + urlencode(nextURL).
The web browser does not 'decode' those parameters at all; the browser doesn't know anything about the parameters but just passes along the string. A query string of the form http://www.example.com/path/to/query?param1=value¶m2=value2 is GET-requested by the browser as:
GET /path/to/query?param1=value¶m2=value2 HTTP/1.1
Host: www.example.com
(other headers follow)
On the backend, you'll need to parse the results. I think PHP's $_REQUEST array will have already done this for you; in other languages you'll want to split over the first ? character, then split over the & characters, then split over the first = character, then urldecode both the name and the value.
According to RFC 3986:
The query component is indicated by the first question mark ("?")
character and terminated by a number sign ("#") character or by the
end of the URI.
So the following URI is valid:
http://www.example.com?next=http://www.example.com
The following excerpt from the RFC makes this clear:
... as query components are often used to carry identifying
information in the form of "key=value" pairs and one frequently used
value is a reference to another URI, it is sometimes better for
usability to avoid percent-encoding those characters.
It is worth noting that RFC 3986 makes RFC 2396 obsolete.
I have a querystring parameter that is an encoded string that gets converted to Base64. That parameter is then embedded in a link within an email. When I click the link in the email, the querystring parameter has had all the + characters within it replaced by space characters. There are no other differences. Is there a method I can call to sanitise the string and effectively replace the spaces with pluses again. I'm currently doing a string replace which is a bit fat hack. Something is causing the replacement but I'm not sure what. Has anyone come across anything like this before?
Example - querystring parameter value within URL of the browser:
yo3rZZbZyG4UCN+L3pcTYJXmWEggnkW1qcyJk2uBrVTtGUSKIlBcJ8e9TSx8BHjHJv0JhI8H6LbIqUl+3lA7qn+lOgpSi3rCGN4bm5moOWcCA449C1Z3zj7J1FkOXH2HMox4VUZ7x7fF65MRwuBBmw==
Value of string within controller action:
yo3rZZbZyG4UCN L3pcTYJXmWEggnkW1qcyJk2uBrVTtGUSKIlBcJ8e9TSx8BHjHJv0JhI8H6LbIqUl 3lA7qn lOgpSi3rCGN4bm5moOWcCA449C1Z3zj7J1FkOXH2HMox4VUZ7x7fF65MRwuBBmw==
You should URL encode the base64 string to the link, so it is:
yo3rZZbZyG4UCN%2BL3pcTYJXmWEggnkW1qcyJk2uBrVTtGUSKIlBcJ8e9TSx8BHjHJv0JhI8H6LbIqUl%2B3lA7qn%2BlOgpSi3rCGN4bm5moOWcCA449C1Z3zj7J1FkOXH2HMox4VUZ7x7fF65MRwuBBmw%3D%3D
HttpUtility.UrlEncode(base64str) in .NET, or encodeURIComponent(base64str) in javascript
you can use System.Web.HttpServerUtility.UrlTokenEncode (from http://brockallen.com/2014/10/17/base64url-encoding/#comments)
It is doing this because the + sign is interpreted as a marker to say that another parameter follows. This is why it is getting mangled. You should URL encode your string before you pass it to the server.
I have an action that expects a string containing a path to a resource ie "/123/something.html"
I am trying to user HttpUtility.UrlEncode() to encode the parameter but then the slashes are encoded to contain '%' characters and this results in a 400 error from the server. How can work around this in ASP.NET MVC2?
you certainly can pass those characters in a URL but they just have to be passed in the query string in the part after the question mark
Ex : http://localhost/servercrm/contacts/query?search=%25%20%25
So, if there are url encoded segments in my apps MVC url, IIS throws a BAD REQUEST 400.
e.g.
http://u.lasoo.com.au/Offer/*9289--750W-Generic-ATX12V-Power-Supply-%252449dot99/6355
<--- the '*' and '%' are causing this error.
Notice that http://u.lasoo.com.au/Offer/The-Giant-Good-As-Gone-7-Day-Sale/6354 works fine.
What's the correct way to convert an arbitrary string into an accepted MVC URL segment?
UPDATE: the URl segment should resemble the original string. Base64 encoding completely transformed the string.
Instead of passing the info in the url you can pass it as a get parameter. Like this:
http://u.lasoo.com.au/Offer/?id=*9289--750W-Generic-ATX12V-Power-Supply-%252449dot99/6355
Have you tried UrlEncode? MSDN
Try a string replace to strip out or substitute symbols ":", "%", "*", "/" - any symbols illegal within a folder name. They seem to screw up everything royally and appear to be a design weakness of the URL routing system.