Talk:URL redirection/Archives/2013

Article needs to be slit or rewritten
I have tried to find the debate on mergeing but without success. While it is clear that all of the issues/topics addressed in this article can logically be grouped together that is not the same as concluding that they should be.

For an encyclopedia to merge articles there should be a clear rationale that shows *BOTH* that this can be done *AND' that it should be done. Clearly the first requirement has been met and the second has not. For it to be shown that articles *SHOULD* be merged it would be necessary to show that there was no benefit to having separate articles. It must be shown that, in the articles to be merged, the overlap between the subjects, assuming that the articles are *complete* is significantly greater than their difference.

However, the significance of any overlap should be judged by how specific any overlap is to the articles to be merged not, and not through size alone. Theoretically any *perfect* article would have to contain all the information there is, because all meaning is systemic i.e. that any and every explanation relies and rests upon other explanations. So the overlap between two articles and the significance of this overlap is not dependent solely on the size of the overlap, and its signifcance decreases the more it is shared between other articles.

This article seems to me to be a tangle of stubs, grouped. To merge URL Shortening into Redirection generally seems to be rather like mergeing all the articles on computer programming languages into one, or all the articles on birds, etc etc.

URL shortening seems to me hardly related at all to the other forms of redirection discussed, except in a very general way. The reason I came to wiki was because the question came into my mind: How is it possible for every URL to be shortened? And then: What are the limits of URL shortening? The answer to my questions will appear obvious to anyone who understand the technology but they do not appear in the article. If the article was to be expanded to explain shortening then this explation would be bigger than one explaing how a simple signpost redirect works.

However, it could be that shortening is just that, merely a signpost. But then that would logically mean that URL shortening, as used for instance on Twitter, will have a very limited shelf life because as the URLs are used by more and more people, and as each person will require a different shortening, they will approach the length of the original in may cases. URL shortening is central to Twitter and others and normal redirects are hardly worthy of more than a couple of lines. It would be intresting to have read how that proces will unfold or is unfolding and what rejections can be made about their shelf life. Of course URLs with perhaps a hundred characters or so will always benefit from being shortened, but it is likely that bit owl etc will die out as their shortenings become so long as to render them benefitless, and as sites that generate long URLs adopt their own specific shortening databases. All these questions would be answered in a decent article on URL shortening. If they were answered in the curent article they would drown out the rest.

Anyway, I'm just making all this up. There is probably more to understand.

In addition to this, even with the mergeing, the article as it stands seems to me to be full of weasel phrases and conjecture. LookingGlass (talk) 07:19, 17 May 2009 (UTC)
 * I agree with you so much that I created URL shortening. I may address some of the problems you pose. Letuño (talk) 16:42, 14 June 2009 (UTC)

A question of scope
See Talk:HTTP_URL_aliasing. Dro Kulix 06:04, 12 May 2006 (UTC)

Absolute URI for redirects
The "Using server side scripting for Redirection" section mentions that "According to the HTTP standard, the Location header must contain an absolute URI". I had always been under the impression that this was the case, but cannot find the specific reference in the HTTP spec (which is linked). Can someone find it and, if possible, modify the link to point to the appropriate section? —Preceding unsigned comment added by Bobbykjack (talk • contribs) 09:37, 14 December 2007 (UTC)
 * Added citation. --Jplarocque (talk) 17:01, 7 October 2008 (UTC)

306 not used
A search of the HTTP working group archives reveals that, at one time, this code was named Switch Proxy. Currently its value is: "Not used", which does not mean you can use it for unused urls. —Preceding unsigned comment added by 80.126.226.120 (talk) 10:37, 18 June 2008 (UTC)

Redirection Responses Have Bodies
When a server responds with 301 or 302, the response is allowed to have a body. "Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s)." --Jplarocque (talk) 17:01, 7 October 2008 (UTC)

htmlspecialchars
The article states "If the input is not sanitized (using htmlspecialchars) someone could be supplied with a URL that executes some malicious JavaScript appearing to originate from the website hosting the PHP code." next to the PHP code. This is incorrect, htmlspecialchars replaces specific html related characters with their html entities, it does not remove "javascript:" from the begining of a URL, and therefore javascript code will work. I'm removing that text for now. --Nezek (talk) 22:43, 8 February 2009 (UTC)

domain redirection and domain forwarding
domain redirection/domain forwarding are different from URL redirection. Because the latter is done in http level while the first is done in DNS level. I guess this needs a clarification or edit in the article. mixdev (talk) 18:38, 4 April 2009 (UTC)

Don't confuse memorable and short
Throughout this article the words memorable and short are confused. The goals of http://www.myforum.on.to/ and http://tinyurl.com/87hjk6 are not the same. The first URL must be memorable, even if it takes several hours to setup. The second one must be short and easily generated.

I know only one site devoted to both types of redirection, and it is .tk. There you can register http://www.myforum.tk/ or (vía Tweak.tk) generate a short URL such as http://gt60f.tk/ to post on Twitter.

Letuño (talk) 22:31, 14 June 2009 (UTC)

Suggesting a link
I hope that my tutorial on HTTP redirects (301, 302, 307) can be a useful resource for this article: http://sebastians-pamphlets.com/the-anatomy-of-http-redirects-301-302-307/ I'm not sure it's appreciated when I add the link myself. Sebastian —Preceding unsigned comment added by SebastiansPamphlets (talk • contribs) 11:30, 17 August 2009 (UTC)

@Wknight94, that's not link spam. I didn't add the link myself but posted it to the discussion page because I thought adding my own stuff could look too promotional. Please go read the article at http://sebastians-pamphlets.com/the-anatomy-of-http-redirects-301-302-307/ before you consider it crap. Thanks, Sebastian.

Why redirect .hack here?
Why does .hack redirect here? RocketMaster (talk) 11:50, 29 November 2009 (UTC)
 * And why does "Software cracking" redirect here? Is that a result of vandalism or a result of the "legal vandalism" commited by the copyright mafia? This looks really worrying and confusing. 213.39.190.167 (talk) 04:04, 12 January 2010 (UTC)

bad —Preceding unsigned comment added by 86.62.13.182 (talk) 03:41, 20 January 2010 (UTC)

URL obfuscation services
I did not understand the part about "URL obfuscation services".

The connection the text makes to anonymity made me think of IP hiding, but I do not think this is what is referred to? I put the code supplied in the text onto my own PHP5 server and it redirected me to a non-existing page in a subfolder on my own server, I think it was this page: http://example.org/redirect.php/http://www.google.com I do not think that was the intention. I then changed this $url = urlencode($_GET['url']); to this $url = $_GET['url'];

Then the code, as expected, redirected me to http://www.google.com But no obfuscation of the url occurs, I can still see www.google.com in the browser address window.

I could well have misunderstood something, but the text was easy to read up to the part of "URL obfuscation". I think it should be explained better. (since I do not understand it ;) )

I apologize if i broke any rule, just tell me, I am new here.

Ycc Sweden (talk) 09:23, 10 November 2010 (UTC)


 * yep you're right, but if you would have read it, it says clearly that its for hiding the referring URL. Its true though that it has nothing to do with "obfuscation".
 * Second, the PHP snippet is terrible. Its wrong for one (if you do not include a URL it will give you errors), and also its insecure because someone could inject html/javascript into the page.
 * Not sure what the point is. If you cant do it right then its not worth including in the article. 98.237.96.174 (talk)


 * I agree that the PHP script currently in the article is confusing to non-experts, and thus should either be fixed (i.e. explained better) or removed.
 * —DIV (138.194.11.244 (talk) 08:40, 11 September 2011 (UTC))

Suggesting a link that has two reasons not to be included in Wikipedia
This link:

Redirecting your visitors to your preferred domain

was reverted by bot for apparently two good reasons:


 * 1) Links normally to be avoided Section 11
 * 2) Advertising and conflicts of interest - I wrote that article.

XLinkBot appears to blindly remove links to any content that contains blogspot.com, I've therefore added it again leaving it to the moderators to decide if the link should be eliminated. In my humble opinion, the link is relevant.

--Schwarzenneger (talk) 06:29, 8 April 2011 (UTC)