I use bit.ly to shorten my urls.
My problem - paramters are not passed.
Let me explain I use http://bit.ly/MYiPhoneApps which redirects (let's say) to http://iphone.pp-p.net/default.aspx
Now when I try http://bit.ly/MYiPhoneApps?param=xx this param is not added to the resulting url.
I know I could create an extra "short url" including a paramter - so http://bit.ly/WithParam would result in http://www.mysite.com/somepath/apage.aspx?Par1=yy and so forth.
But what I want is to have a short URL directing to a page - and then I want to add a parameter to this shortened url - which shoul (of course) land at my page.
Is this a shortcome of bit.ly (and others are maybe able to do it) - or does "parameter forwarding" not work with 301 redirections?
Manfred
There's no technical reason why it couldn't be done. The service would simply have to look at what parameters it is being sent, and then rewrite the target URL accordingly.
The problem is that it's not necessarily well defined how to do that.
Suppose you have the url http://example.com/default.aspx?foo=bar, and it has the short url http://foo.com/ABCD. What should happen if you try to access http://foo.com/ABCD?foo=baz? Should it replace the value, so you get foo=baz? Should it append it to make foo=bar&foo=baz? If we include both, which order should they be in?
The system cannot know which parameters are safe to override and which are not, because sometimes, you DO want both of them in the URL, and it may matter what order things are added in.
You could argue "Well, just don't allow this for URLs where parameters are already present", but there's also the issue that it's going to complicate the process a lot more. Without this, you just lookup a key in a database and send a redirect header. Now, you need to also analyze the URL to check for parameters, and append part of the URL you were called by. That requires more system resources per redirect, which may become a big problem if your service is used very frequently - you'll need more server power to handle the same amount of redirects. I don't think that tradeoff is considered to be "worth it".
As mentioned in comments by rinogo and Jurgen
In Clickmeter
Destination URL : www.yoursite.com?myparam1={id1}&myparam2={id2}
Tracking link : www.go.clickmeter.com/38w2?id1=123&id2=abc
After click : www.yoursite.com?myparam1=123&myparam2=abc
In TinyUrl
Destination URL : http://x.com?a=1
Shorten URL : https://tiny url.com/y6gh7ovk
Shorten URL + param : https://tiny url.com/y6gh7ovk?a=2
Resultant URL : http://x.com/?a=1&a=2
Added space to post tinyurl
URL shortening associates a unique key based on a full URL (parameters and all), so it is not possible to pass parameters to a shortening service.
Typically
http://iphone.pp-p.net/default.aspx?param=10
must produce a different key to
http://iphone.pp-p.net/default.aspx?param=22
'Parameter forwarding' is simply not possible in these kinds of redirects, as parameters are not valid parts of a shortened URL is most (if not all) services.
Related
I'm trying to add param in the url, like in this example:
https://www.google.com/ > https://www.google.com/search?q=qq
Opening the last link you can see "qq" in the "q" input.
For this site it doesn't work (this is the problem):
https://www.calabriasue.it/assistenza/richiesta-assistenza-e-supporto/
https://www.calabriasue.it/assistenza/richiesta-assistenza-e-supporto/?nome=mario
Can I add url param also in the last one? I need it.
Thanks!
I tried using different input names, different params ecc but it doesn't work.
Google's server side code is designed to generate an HTML document with an input field that is prefilled with the current search term which is reads from the URL. That is why adding q=search+term to the URL populates the input field.
You can't make arbitrary third-party websites prefill inputs. They have to explicitly provide a mechanism to make it possible.
Parameters only work as long as the code for the target website is expecting to handle a parameter named "nome" with a value "mario". In the case of the google website, it is expecting a parameter named "q" and has a form input for it.
Clicking a URL sends a a GET request type, and the target site may only be accepting parameters from a POST request type. You could consider using the application known as "PostMan" to help with that.
Alternately, the target page you are viewing may be forwarded / routed from a different page which accepts parameters.
Like the question says, how do I add a parameter to a URL?
Example:
When you click on a link to get a featured product on Product Hunt, the URL is appended with ?ref=producthunt.
Can I just add a parameter like this manually to the few links that I have on my website? Are there any scenarios where this might be suboptimal to do?
The parameters in the URL correspond to the superglobal $_GET array.
It means that if your URL is in the form
www.domain.com?key1=val1&key2=val2 ,
then $_GET[key1] contains val1 , and so on.
It is perfectly legitimate to add these parameters manually in a link (a typical use case would be a login button, which redirects you to the current URL and appends &todo=login . You can then add a bit of PHP code that triggers the login process when $_GET contains the value 'login' at the key 'todo').
The other way of adding these parameters is forms. In an HTML form, you specify a 'method' which can be 'get' or 'post'.
If you choose 'get', when the form is submitted, the URL will automatically be appended with the form answers.
NB: It is generally NOT SAFE to directly read values from the $_GET, as the user can fill it with any value (just by changing the URL) so it is good practice to use filters that ensure inputs are safe. Check http://www.w3schools.com/php/php_filter.asp for more on filters
The parameters added to the url is called query string and they have a format
it must start will ?
every paraper will be seperated with &
Example: http://www.yoururl.com?name=myname&age=34&ect=somethingelse
The mistake you did is by putting ?= which is not converted by your web server.
you can pas like '?websitename=website-name'
Querystring parameters are key value pairs that are separated from the URL's domain and path with a ? and separated from each other with an &, i.e ?key=value&key2=value2.
The values can be accessed client-side (in Javascript) and server-side by the webserver or by a server-side language is being used, PHP, ASP.NET, Java.
Some values should be encoded using a function such as encodeURIComponent to ensure that they are valid.
Risks
You need to be careful that the querystring does not contain any sensitive information such as a sequential order number, i.e ?order=5 as someone could manually change the value to see another user's order (?order=6, if no other authentication in place). The order value should be encrypted so it cannot be guessed. Also, do not execute any code passed in on the querystring with eval() as the contents could be changed by a malicious user to execute a crosssite scripting (XSS) attack on another user and steal their cookie or login credentials.
JWebUnit.beginAt:
Begin conversation at a URL absolute or relative to base URL. Use getTestContext().setBaseUrl(String) to define base URL. Absolute URL should start with "http://", "https://" or "www.".
JWebUnit.gotoPage:
Go to the given page like if user has typed the URL manually in the browser. Use getTestContext().setBaseUrl(String) to define base URL. Absolute URL should start with "http://", "https://" or "www.".
So, one says "Begin conversation at URL absolute or relative to base URL", while the other says "Go to the given page like if user has typed the URL manually in the browser". This doesn't help me in the slightest in understanding them (well, specifically the former; the latter makes sense). What's the actual difference between them? Which should I be using, and when?
I finally did manage to find the answer in the source code.
beginAt does two things: start the browser, then call gotoPage with its argument. Thus, you need to use beginAt the first time, and gotoPage subsequent times. (Perhaps if managing multiple windows it has more use; I haven't dug that deeply.)
If an extra character (like a period, comma or a bracket or even alphabets) gets accidentally added to URL on the stackoverflow.com domain, a 404 error page is not thrown. Instead, URLs self correct themselves & the user is led to the relevant webpage.
For instance, the extra 4 letters I added to the end of a valid SO URL to demonstrate this would be automatically removed when you access the below URL -
https://stackoverflow.com/questions/194812/list-of-freely-available-programming-booksasdf
I guess this has something to do with ASP.NET MVC Routing. How is this feature implemented?
Well, this is quite simple to explain I guess, even without knowing the code behind it:
The text is just candy for search engines and people reading the URL:
This URL will work as well, with the complete text removed!
The only part really important is the question ID that's also embedded in the "path".
This is because EVERYTHING after http://stackoverflow.com/questions/194812 is ignored. It is just there to make the link, if posted somewhere, if more speaking.
Internally the URL is mapped to a handler, e.g., by a rewrite, that transforms into something like: http://stackoverflow.com/questions.php?id=194812 (just an example, don't know the correct internal URL)
This also makes the URL search engine friendly, besides being more readable to humans.
I am accessing a set of websites using variables
<cfhttp url="http://website.com/index.php?title=#var1#:#var2#&action=edit##EditPage" method="GET">
Some pages do not provide the data I need and instead of #EditPage in the URL show a fragment
edit&redlink=1. I want to treat these pages differently. How do I go about identifying them?
The hash "#" used in URL is used by browsers and not servers. Typically when a browser sees the hash in the URL it will jump to either an anchor on the page with the same name, or an element with that id. Exceptions, are when javascript is used to modify the page dynamically based on the hash.
If I'm understanding you correctly, what you want to do is construct the URL in a separate variable first. Something like URLtoGet. Then, you can use cfif to switch on whether that constructed URL contains the fragment you specified. Look into contains(), find(), and findNoCase() to determine which is the best option for you.