URL redirection: Difference between revisions

Revision as of 10:00, 10 October 2024

Latest revision as of 05:18, 27 August 2025

(36 intermediate revisions by 29 users not shown)

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