URL redirection: Difference between revisions

Revision as of 14:00, 1 October 2024

Latest revision as of 05:18, 27 August 2025

(37 intermediate revisions by 30 users not shown)

Line 80:

In the [[HTTP]] [[Protocol (computing)|protocol]] used by the [[World Wide Web]], a '''redirect''' is a response with a [[List of HTTP status codes|status code]] beginning with ''3'' that causes a browser to display a different page. If a client encounters a redirect, it needs to make a number of decisions how to handle the redirect. Different status codes are used by clients to understand the purpose of the redirect, how to handle caching and which request method to use for the subsequent request.

HTTP/1.1 defines several status codes for redirection ([https://tools.ietf.org/html/rfc7231 RFC 7231]):

* [[HTTP 300|300 multiple choices]] (e.g. offer different languages)

* [[HTTP 301|301 moved permanently]] (redirects permanently from one URL to another passing link equity to the redirected page)

Line 108:

|}

All of these status codes require the URL of the redirect target to be given in the "Location:" header of the HTTP response. The 300 multiple choices will usually list all choices in the body of the message and show the default choice in the "Location:" header.

==== Example HTTP response for a 301 redirect ====

Line 140:

</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}} ====

Line 159:

==== 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). A showingAn example of such advanced use of the rewrite module is [https://mdoc.su/ mdoc.su] {{Webarchive|url=https://web.archive.org/web/20220403132148/http://mdoc.su/ |date=3 April 2022 }}, 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" />

Line 204:

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";

Line 249:

=== Redirect chains ===

{{redirect|Double redirect|Wikipedia'sinformation guidelineabout ondouble Doubleredirects redirecton Wikipedia|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.

Line 259:

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>

Line 315:

<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 | archive-date=7 December 2014 | archive-url=https://web.archive.org/web/20141207181229/https://www.owasp.org/index.php/Open_redirect | url-status=dead }}</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 | archive-date=10 March 2016 | archive-url=https://web.archive.org/web/20160310005903/http://tetraph.com/covert_redirect/ | url-status=dead }}</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>

Line 325:

<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=httphttps://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=httphttps://mailman.nginx.org/pipermail/nginx/2013-February/037592.html |mailing-list=[e-mail] |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>

Line 332:

<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=httphttps://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=httphttps://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=httphttps://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>