Editing URL redirection (section)

=Moved=
<p>This page has moved to <a href="https://www.example.org/">https://www.example.org/</a>.</p>
</body>
</html>
</syntaxhighlight>

==== Using server-side scripting for redirection ====
Web authors producing HTML content can't usually create redirects using HTTP headers as these are generated automatically by the web server program when serving an HTML file.  The same is usually true even for programmers writing CGI scripts, though some servers allow scripts to add custom headers (e.g. by enabling "non-parsed-headers").  Many web servers will generate a 3xx status code if a script outputs a "Location:" header line.  For example, in [[PHP]], one can use the "header" function:

<syntaxhighlight lang="php">
header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/');
exit();
</syntaxhighlight>

More headers may be required to prevent caching.<ref name="php-301-robust-solution" /> The programmer must ensure that the headers are output before the body.  This may not fit easily with the natural flow of control through the code.  To help with this, some frameworks for server-side content generation can buffer the body data.  In the [[Active Server Pages|ASP scripting]] language, this can also be accomplished using <code>response.buffer=true</code> and <code>response.redirect <nowiki>"https://www.example.com/"</nowiki></code> HTTP/1.1 allows for either a relative URI reference or an absolute URI reference.<ref name="venDA" /> If the URI reference is relative the client computes the required absolute URI reference according to the rules defined in [https://tools.ietf.org/html/rfc3986 RFC 3986].<ref name="3Y1IG" />

==== Apache HTTP Server mod_rewrite{{anchor|mod_rewrite}} ====
The [[Apache HTTP Server]] mod_alias extension can be used to redirect certain requests. Typical configuration directives look like:
<syntaxhighlight lang="apache">
Redirect permanent /oldpage.html https://www.example.com/newpage.html
Redirect 301 /oldpage.html https://www.example.com/newpage.html
</syntaxhighlight>

For more flexible [[URL rewriting]] and redirection, Apache mod_rewrite can be used. E.g., to redirect a requests to a canonical domain name:
<syntaxhighlight lang="apache">
RewriteEngine on
RewriteCond %{HTTP_HOST} ^([^.:]+\.)*oldsite\.example\.com\.?(:[0-9]*)?$ [NC]
RewriteRule ^(.*)$ https://newsite.example.net/$1 [R=301,L]
</syntaxhighlight>

Such configuration can be applied to one or all sites on the server through the server configuration files or to a single content directory through a <code>[[.htaccess]]</code> file.

==== nginx rewrite ====
[[Nginx]] has an integrated http rewrite module,<ref name="T6lN6" /> which can be used to perform advanced URL processing and even web-page generation (with the <code>return</code> directive).  An example of such advanced use of the rewrite module is mdoc.su, which implements a deterministic [[URL shortening]] service entirely with the help of nginx configuration language alone.<ref name="ltnoQ" /><ref name="sjHzb" />

For example, if a request for <code>[https://www.dragonflybsd.org/cgi/web-man?command=HAMMER&section=5 /DragonFlyBSD/HAMMER.5]</code> were to come along, it would first be redirected internally to <code>/d/HAMMER.5</code> with the first rewrite directive below (only affecting the internal state, without any HTTP replies issued to the client just yet), and then with the second rewrite directive, an [[HTTP response]] with a [[HTTP 302|302 Found status code]] would be issued to the client to actually redirect to the external [[Common Gateway Interface|cgi script]] of web-[[man page|man]]:<ref name="y0ZUF" />
<syntaxhighlight lang="nginx">
 location /DragonFly {
  rewrite ^/DragonFly(BSD)?([,/].*)?$ /d$2 last;
 }
 location /d {
  set $db "https://leaf.dragonflybsd.org/cgi/web-man?command=";
  set $ds "&section=";
  rewrite ^/./([^/]+)\.([1-9])$  $db$1$ds$2 redirect;
 }
</syntaxhighlight>

=== Refresh Meta tag and HTTP refresh header ===
[[Netscape]] introduced the [[meta refresh]] feature which refreshes a page after a certain amount of time.  This can specify a new URL to replace one page with another.  This is supported by most web browsers.<ref name="iFTFs" /><ref name="BEKGZ" /> A timeout of zero seconds effects an immediate redirect. This is treated like a 301 permanent redirect by Google, allowing transfer of PageRank to the target page.<ref name="DOOOW" />

This is an example of a simple HTML document that uses this technique:
<syntaxhighlight lang="html">
<html>
<head>
  <meta http-equiv="Refresh" content="0; url=https://www.example.com/" />
</head>
<body>
  <p>Please follow <a href="https://www.example.com/">this link</a>.</p>
</body>
</html>
</syntaxhighlight>

This technique can be used by [[Web designer|web authors]] because the meta tag is contained inside the document itself.  The meta tag must be placed in the "head" section of the HTML file.  The number "0" in this example may be replaced by another number to achieve a delay of that many seconds.  The anchor in the "body" section is for users whose browsers do not support this feature.

The same effect can be achieved with an HTTP <code>refresh</code> header:
<syntaxhighlight lang="http">
HTTP/1.1 200 OK
Refresh: 0; url=https://www.example.com/
Content-Type: text/html
Content-Length: 78

Please follow <a href="https://www.example.com/">this link</a>.
</syntaxhighlight>

This response is easier to generate by CGI programs because one does not need to change the default status code.

Here is a simple CGI program that effects this redirect:
<syntaxhighlight lang="perl">
# !/usr/bin/env perl
print "Refresh: 0; url=https://www.example.com/\r\n";
print "Content-Type: text/html\r\n";
print "\r\n";
print "Please follow <a href=\"https://www.example.com/\">this link</a>!"
</syntaxhighlight>

Note: Usually, the HTTP server adds the status line and the Content-Length header automatically.

The [[World Wide Web Consortium|W3C]] discourage the use of meta refresh, since it does not communicate any information about either the original or new resource, to the browser (or [[search engine]]). The W3C's Web Content Accessibility Guidelines (7.4)<ref name="DO1Os" /> discourage the creation of auto-refreshing pages, since most web browsers do not allow the user to disable or control the refresh rate.  Some articles that they have written on the issue include [https://www.w3.org/TR/WAI-WEBCONTENT/#gl-movement W3C Web Content Accessibility Guidelines (1.0): Ensure user control of time-sensitive content changes], Use standard redirects: don't break the back button!<ref name="sEvbk" /> and Core Techniques for Web Content Accessibility Guidelines 1.0 section 7.<ref name="V6sLN" />

=== JavaScript redirects ===
[[JavaScript]] can cause a redirect by setting the <code>window.location</code> attribute, e.g.:
<syntaxhighlight lang="javascript">
window.location='https://www.example.com/'
</syntaxhighlight>
Normally JavaScript pushes the redirector site's [[URL]] to the browser's history. It can cause redirect loops when users hit the back button. With the following command you can prevent this type of behaviour.<ref name="knBmq" />
<syntaxhighlight lang="javascript">
window.location.replace('https://www.example.com/')
</syntaxhighlight>
However, HTTP headers or the refresh meta tag may be preferred for security reasons and because JavaScript will not be executed by some browsers and many [[web crawler]]s.

=== Frame redirects ===

A slightly different effect can be achieved by creating an inline [[Frame (World Wide Web)|frame]]:

<syntaxhighlight lang="html">
<iframe height="100%" width="100%" src="https://www.example.com/">
Please follow <a href="https://www.example.com/">link</a>.
</iframe>
</syntaxhighlight>

One main difference to the above redirect methods is that for a frame redirect, the browser displays the URL of the frame document and not the URL of the target page in the URL bar. This ''cloaking'' technique may be used so that the reader sees a more memorable URL or to fraudulently conceal a [[phishing]] site as part of [[website spoofing]].<ref name="G9pV6" />

Before HTML5,<ref name="zW4Ol" /> the same effect could be done with an [[Framing (World Wide Web)|HTML frame]] that contains the target page:
<syntaxhighlight lang="html">
<frameset rows="100%">
  <frame src="https://www.example.com/">
  <noframes>
    <body>Please follow <a href="https://www.example.com/">link</a>.</body>
  </noframes>
</frameset>
</syntaxhighlight>

=== Redirect chains ===
{{redirect|Double redirect|Wikipedia's guideline on Double redirect|Wikipedia:Double redirects}}
One redirect may lead to another in a redirect chain. If a redirect leads to another redirect, this may also be known as a double redirect.<ref name="Schwartz">{{cite web|url=https://www.seroundtable.com/archives/015712.html|title=Double Redirects May Take Google More Time To Pick Up On|last=Schwartz|first=Barry|date=Dec 18, 2007|work=Search Engine Roundtable|access-date=28 January 2024}}</ref> For example, the URL "https://wikipedia.com" (with "*.com" as domain) is first redirected to https://www.wikipedia.org/ (with domain name in [[.org]]), where you can navigate to the [https://en.wikipedia.org/ language-specific site]. This is unavoidable if the different links in the chain are served by different servers though it should be minimised by ''[[rewriting]]'' the URL as much as possible on the server before returning it to the browser as a redirect.

=== Redirect loops ===
Sometimes a mistake can cause a page to end up redirecting back to itself, possibly via other pages, leading to an infinite sequence of redirects. Browsers should stop redirecting after a certain number of hops and display an error message.

The HTTP/1.1 Standard states:<ref name="rfc7231sec6.4" />
<blockquote>
A client ''SHOULD'' detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).

Note: An earlier version of this specification recommended a maximum of five redirections ([https://tools.ietf.org/html/rfc2068 RFC 2068], Section 10.3).  Content developers need to be aware that some clients might implement such a fixed limitation.
</blockquote>

== Services ==
There exist services that can perform URL redirection on demand, with no need for technical work or access to the web server your site is hosted on.

=== URL redirection services ===
A '''redirect service''' is an information management system, which provides an internet link that redirects users to the desired content. The typical benefit to the user is the use of a memorable domain name, and a reduction in the length of the URL or web address. A redirecting link can also be used as a permanent address for content that frequently changes hosts, similarly to the [[Domain Name System]]. Hyperlinks involving URL redirection services are frequently used in spam messages directed at blogs and wikis.  Thus, one way to reduce spam is to reject all edits and comments containing hyperlinks to known URL redirection services; however, this will also remove legitimate edits and comments and may not be an effective method to reduce spam.
Recently, URL redirection services have taken to using [[AJAX]] as an efficient, user friendly method for creating shortened URLs. A major drawback of some URL redirection services is the use of delay pages, or frame based advertising, to generate revenue.

==== History ====
The first redirect services took advantage of [[top-level domains]] (TLD) such as "[[.to]]" (Tonga), "[[.at]]" (Austria) and "[[.is]]" (Iceland). Their goal was to make memorable URLs. The first mainstream redirect service was V3.com that boasted 4 million users at its peak in 2000.  V3.com success was attributed to having a wide variety of short memorable domains including "r.im", "go.to", "i.am", "come.to" and "start.at".  V3.com was acquired by FortuneCity.com, a large free web hosting company, in early 1999.<ref name="2Died" /> As the sales price of top level domains started falling from {{US$|long=no|50.00}} per year to less than {{US$|long=no|10.00}}, use of redirection services declined. With the launch of [[TinyURL]] in 2002 a new kind of redirecting service was born, namely [[URL shortening]]. Their goal was to make long URLs short, to be able to post them on internet forums. Since 2006, with the 140 character limit on the extremely popular [[Twitter]] service, these short URL services have been heavily used.

=== Referrer masking ===
Redirection services can hide the [[referrer]] by placing an intermediate page between the page the link is on and its destination. Although these are conceptually similar to other URL redirection services, they serve a different purpose, and they rarely attempt to shorten or obfuscate the destination URL (as their only intended side-effect is to hide referrer information and provide a clear gateway between other websites.) This type of redirection is often used to prevent potentially-malicious links from gaining information using the referrer, for example a [[session ID]] in the query string. Many large community websites use link redirection on external links to lessen the chance of an exploit that could be used to steal account information, as well as make it clear when a user is leaving a service, to lessen the chance of effective [[phishing]]  .

Here is a simplistic example of such a service, written in [[PHP]].
<syntaxhighlight lang="html+php">
<?php
$url = htmlspecialchars($_GET['url']);
header('Refresh: 0; url=https://' . $url);
?>
<!-- Fallback using meta refresh. -->
<html>
 <head>
  <title>Redirecting...</title>
  <meta http-equiv="refresh" content="0;url=https://<?= $url; ?>">
 </head>
 <body>
 Attempting to redirect to <a href="https://<?= $url; ?>">https://<?= $url; ?></a>.
 </body>
</html>
</syntaxhighlight>

The above example does not check who called it (e.g. by referrer, although that could be spoofed).  Also, it does not check the URL provided.  This means that a malicious person could link to the redirection page using a URL parameter of his/her own selection, from any page, which uses the web server's resources.

==Security issues==

URL redirection can be abused by attackers to perform [[phishing]] attacks. If a redirect target is not sufficiently validated by a web application, an attacker can make a web application redirect to an arbitrary website. This vulnerability is known as an open-redirect vulnerability.<ref name=":0">{{Cite book |last1=Innocenti |first1=Tommaso |last2=Golinelli |first2=Matteo |last3=Onarlioglu |first3=Kaan |last4=Mirheidari |first4=Ali |last5=Crispo |first5=Bruno |last6=Kirda |first6=Engin |chapter=OAuth 2.0 Redirect URI Validation Falls Short, Literally |date=2023-12-04 |title=Annual Computer Security Applications Conference |chapter-url=https://dl.acm.org/doi/10.1145/3627106.3627140 |series=ACSAC '23 |location=New York, NY, USA |publisher=Association for Computing Machinery |pages=256–267 |doi=10.1145/3627106.3627140 |isbn=979-8-4007-0886-2|hdl=11572/399070 |hdl-access=free }}</ref><ref name="Open_Redirect"/> In certain cases when an open redirect occurs as part of an [[authentication]] flow, the vulnerability is known as a covert redirect.<ref name="Covert_Redirect" /><ref name="CNET" /> When a covert redirect occurs, the attacker website can steal [[Authentication cookie|authentication information]] from the victim website.<ref name=":0" /> Open redirect vulnerabilities are fairly common on the web. In June 2022, TechRadar found over 25 active examples of open redirect vulnerabilities on the web, including sites like [[Google]] and [[Instagram]].<ref>{{Cite web |author1=Mike Williams |date=2022-06-05 |title=What is an Open Redirect vulnerability, why is it dangerous and how can you stay safe? |url=https://www.techradar.com/features/what-is-open-redirect-vulnerability |access-date=2024-04-08 |website=TechRadar |language=en}}</ref> Open redirects have their own CWE identifier, CWE-601.<ref>{{Cite web |title=CWE - CWE-601: URL Redirection to Untrusted Site ('Open Redirect') (4.14) |url=https://cwe.mitre.org/data/definitions/601.html |access-date=2024-04-08 |website=cwe.mitre.org}}</ref>

URL redirection also provides a mechanism to perform [[cross-site leak]] attacks. By timing how long a website took to return a particular page or by differentiating one destination page from another, an attacker can gain significant information about another website's state. In 2021, Knittel et al. discovered a vulnerability in the Chrome's Performance API implementation which allowed them to reliably detect cross-origin redirects.<ref>{{Cite book |last1=Knittel |first1=Lukas |last2=Mainka |first2=Christian |last3=Niemietz |first3=Marcus |last4=Noß |first4=Dominik Trevor |last5=Schwenk |first5=Jörg |chapter=XSinator.com: From a Formal Model to the Automatic Evaluation of Cross-Site Leaks in Web Browsers |date=2021-11-13 |title=Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security |chapter-url=https://dl.acm.org/doi/10.1145/3460120.3484739 |series=CCS '21 |location=New York, NY, USA |publisher=Association for Computing Machinery |pages=1771–1788 |doi=10.1145/3460120.3484739 |isbn=978-1-4503-8454-4}}</ref> 

==See also==
<!---♦♦♦ Please keep the list in alphabetical order ♦♦♦--->
* [[Canonical link element]]
* [[Clean URL]]
* [[Domain masking]]
* [[HTTP location]]
* [[Link rot]]
* [[URI normalization]]

==References==
{{reflist|refs=
<ref name="NtrEdf">{{cite journal | title = Google revives redirect snoopery | website = Blog.anta.net | date = 29 January 2009 | url = http://blog.anta.net/2009/01/29/509/ | issn = 1797-1993 | archive-url=https://web.archive.org/web/20110817024348/http://blog.anta.net/2009/01/29/509/ | archive-date=17 August 2011}}</ref>
<ref name="php-301-robust-solution">{{cite web|url=http://www.websitefactors.co.uk/php/2011/05/php-redirects-302-to-301-rock-solid-solution/ |title=PHP Redirects: 302 to 301 Rock Solid Robust Solution |publisher=WebSiteFactors.co.uk |archive-url=https://web.archive.org/web/20121012042703/http://www.websitefactors.co.uk/php/2011/05/php-redirects-302-to-301-rock-solid-solution |archive-date=12 October 2012}}</ref>
<ref name="rfc7231sec6.4">{{cite IETF | title = Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content | rfc = 7231 | section = 6.4 | sectionname = Redirection 3xx | page = 54 | editor1 = Roy T. Fielding | editor1-link = Roy Fielding | editor2 = Julian F. Reschke | year = 2014 | publisher = [[Internet Engineering Task Force|IETF]]}}</ref>
<ref name="Open_Redirect">{{cite web | url=https://www.owasp.org/index.php/Open_redirect | title=Open Redirect |publisher= OWASP |date=16 March 2014 | access-date=21 December 2014}}</ref>
<ref name="Covert_Redirect">{{cite web | url=http://tetraph.com/covert_redirect/ | title=Covert Redirect |publisher= Tetraph |date=1 May 2014 | access-date=21 December 2014}}</ref>
<ref name="CNET">{{cite web | url=https://www.cnet.com/news/serious-security-flaw-in-oauth-and-openid-discovered/ | title=Serious security flaw in OAuth, OpenID discovered |publisher= CNET |date=2 May 2014 | access-date=21 December 2014}}</ref>
<ref name="KFihp">{{Cite web |url=https://audisto.com/insights/guides/31/ |title=Redirects & SEO - The Total Guide |access-date=29 November 2015 |publisher=Audisto}}</ref>
<ref name="NAY3X">{{cite web|url=https://www.mattcutts.com/blog/seo-advice-discussing-302-redirects/ |title=SEO advice: discussing 302 redirects |date=4 January 2006 |publisher=Matt Cutts, former Head of Google Webspam Team}}</ref>
<ref name="vMaE1">{{cite web|url=https://support.google.com/webmasters/answer/2721217?hl=en |title=Sneaky Redirects |date=3 December 2015 |publisher=Google Inc.}}</ref>
<ref name="XP9Dh">{{cite web|url=https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet |title=Unvalidated Redirects and Forwards Cheat Sheet |date=21 August 2014 |publisher=Open Web Application Security Project (OWASP)}}</ref>
<ref name="G1Lfc">{{Cite web |url=https://audisto.com/insights/guides/31/ |title=Redirects & SEO - The Complete Guide |access-date=29 November 2015 |publisher=Audisto}}</ref>
<ref name="venDA">{{cite IETF | title = Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content | rfc = 7231 | section = 7.1.2 | sectionname = Location | page = 68 | editor1 = Roy T. Fielding | editor2 = Julian F. Reschke | year = 2014 | publisher = [[Internet Engineering Task Force|IETF]]}}</ref>
<ref name="3Y1IG">{{cite IETF | title = Uniform Resource Identifier (URI): Generic Syntax | rfc = 3986 | section = 5 | sectionname = Reference Resolution | page = 28 | first1 = Tim | last1 = Berners-Lee | author1-link = Tim Berners-Lee | first2 = Roy T. | last2 = Fielding | author2-link = Roy Fielding | first3 = Larry | last3 = Masinter | year = 2005 | publisher = [[Internet Engineering Task Force|IETF]]}}</ref>
<ref name="T6lN6">{{cite web|url=http://nginx.org/r/rewrite |title=Module ngx_http_rewrite_module - rewrite |publisher=nginx.org |access-date=24 December 2014}}</ref>
<ref name="ltnoQ">{{cite mailing list |date=18 February 2013 |url=http://mailman.nginx.org/pipermail/nginx/2013-February/037592.html |mailing-list=nginx@nginx.org |title=A dynamic web-site written wholly in nginx.conf? Introducing mdoc.su! |first=Constantine A. |last=Murenin |access-date=24 December 2014}}</ref>
<ref name="sjHzb">{{cite web |url=http://mdoc.su/ |title=mdoc.su – Short manual page URLs for FreeBSD, OpenBSD, NetBSD and DragonFly BSD |first=Constantine A. |last=Murenin |date=23 February 2013 |access-date=25 December 2014}}</ref>
<ref name="y0ZUF">{{cite web |url=http://nginx.conf.mdoc.su/mdoc.su.nginx.conf |title=mdoc.su.nginx.conf |first=Constantine A. |last=Murenin |date=23 February 2013 |access-date=25 December 2014}}</ref>
<ref name="iFTFs">{{cite web|url=https://www.w3schools.com/tags/tag_meta.asp|title=HTML meta tag|website=www.w3schools.com}}</ref>
<ref name="BEKGZ">{{cite web|url=http://wp.netscape.com/assist/net_sites/pushpull.html|title=An Exploration of Dynamic Documents|date=2 August 2002|url-status=bot: unknown|archive-url=https://web.archive.org/web/20020802170847/http://wp.netscape.com/assist/net_sites/pushpull.html|archive-date=2 August 2002|df=dmy-all}}</ref>
<ref name="DOOOW">[http://sebastians-pamphlets.com/google-and-yahoo-treat-undelayed-meta-refresh-as-301-redirect/ "Google and Yahoo accept undelayed meta refreshs as 301 redirects"]. Sebastian's Pamphlets. 3 September 2007.</ref>
<ref name="DO1Os">{{cite web|url=http://www.w3.org/TR/WAI-WEBCONTENT/#tech-no-periodic-refresh|title=Web Content Accessibility Guidelines 1.0|website=www.w3.org}}</ref>
<ref name="sEvbk">{{cite web|url=http://www.w3.org/QA/Tips/reback|title=Use standard redirects|first=the QA|last=Team|website=www.w3.org}}</ref>
<ref name="V6sLN">{{cite web|url=http://www.w3.org/TR/WCAG10-CORE-TECHS/#auto-page-refresh|title=Core Techniques for Web Content Accessibility Guidelines 1.0|website=www.w3.org}}</ref>
<ref name="knBmq">{{cite web|url=http://insider.zone/tools/client-side-url-redirect-generator/|title=Cross-browser client side URL redirect generator|publisher=Insider Zone|access-date=27 August 2015|archive-date=26 July 2020|archive-url=https://web.archive.org/web/20200726044044/http://insider.zone/tools/client-side-url-redirect-generator/|url-status=dead}}</ref>
<ref name="G9pV6">Aaron Emigh (19 January 2005). [http://www.sfbay-infragard.org/Documents/phishing-sfectf-report.pdf "Anti-Phishing Technology"] {{Webarchive|url=https://web.archive.org/web/20070927171420/http://www.sfbay-infragard.org/Documents/phishing-sfectf-report.pdf |date=27 September 2007}} (PDF). Radix Labs.</ref>
<ref name="zW4Ol">{{cite web|url=https://www.w3.org/TR/html5/obsolete.html|title=HTML 5.2: 11. Obsolete features|website=www.w3.org}}</ref>
<ref name="2Died">{{cite news | url=http://news.bbc.co.uk/2/hi/technology/6991719.stm | work=BBC News | title=Net gains for tiny Pacific nation | date=14 September 2007 | access-date=27 May 2010 | url-status=dead | archive-url=https://web.archive.org/web/20140512232450/http://news.bbc.co.uk/2/hi/technology/6991719.stm | archive-date=12 May 2014 | df=dmy-all}}</ref>
}}

==External links==
* [https://httpd.apache.org/docs/2.4/en/urlmapping.html Mapping URLs to Filesystem Locations - Apache HTTP Server Version 2.4]
* [http://www2007.org/workshops/paper_115.pdf Taxonomy of JavaScript Redirection Spam] (Microsoft Live Labs)
* [http://projects.webappsec.org/URL-Redirector-Abuse Security vulnerabilities in URL Redirectors] The Web Application Security Consortium Threat Classification

{{Spamming}}

[[Category:URL|redirection]]
[[Category:Black hat search engine optimization]]
[[Category:Internet search]]
[[Category:Internet terminology]]