URL redirection

Uses your system voice; voice and rate in settings.

Snapshot

≈ 8 min read

Names in other languages

No names in other languages are held for this entry yet.

Article bodies are English and are not machine-translated. A name in another language is not a translation of the article.

URL redirection, also called URL forwarding, is a World Wide Web technique for making a web page available under more than one URL address. When a web browser attempts to open a URL that has been redirected, a page with a different URL is opened. Similarly, domain redirection or domain forwarding is when all pages in a URL domain are redirected to a different domain, as when wikipedia.com and wikipedia.net are automatically redirected to wikipedia.org. URL redirection is done for various reasons: * for URL shortening; * to prevent broken links when web pages are moved; * to allow multiple domain names belonging to the same owner to refer to a single web site; * to guide navigation into and out of a website; * for privacy protection (such as redirecting YouTube and Twitter links to Invidious and Nitter respectively or to turn AMP links into normal links); and * for hostile purposes such as phishing attacks or malware distribution.

URL redirection, also called URL forwarding, is a World Wide Web technique for making a web page available under more than one URL address. When a web browser attempts to open a URL that has been redirected, a page with a different URL is opened. Similarly, domain redirection or domain forwarding is when all pages in a URL domain are redirected to a different domain, as when wikipedia.com and wikipedia.net are automatically redirected to wikipedia.org. URL redirection is done for various reasons: for URL shortening; to prevent broken links when web pages are moved; to allow multiple domain names belonging to the same owner to refer to a single web site; to guide navigation into and out of a website; for privacy protection (such as redirecting YouTube and Twitter links to Invidious and Nitter respectively or to turn AMP links into normal links); and for hostile purposes such as phishing attacks or malware distribution. Please follow this link . This method is often used as a fall-back — if the browser does not support the automatic redirect, the visitor can still reach the target document by following the link. HTTP/1.1 301 Moved Permanently Location: https://www.example.org/ Content-Type: text/html Content-Length: 174 Moved =Moved= This page has moved to https://www.example.org/ . header('HTTP/1.1 301 Moved Permanently'); header('Location: https://www.example.com/'); exit(); More headers may be required to prevent caching. 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 ASP scripting language, this can also be accomplished using response.buffer=true and response.redirect "https://www.example.com/" HTTP/1.1 allows for either a relative URI reference or an absolute URI reference. If the URI reference is relative the client computes the required absolute URI reference according to the rules defined in RFC 3986. Redirect permanent /oldpage.html https://www.example.com/newpage.html Redirect 301 /oldpage.html https://www.example.com/newpage.html For more flexible URL rewriting and redirection, Apache mod_rewrite can be used. E.g., to redirect a requests to a canonical domain name: RewriteEngine on RewriteCond %{HTTP_HOST} ^([^.:]+\.)*oldsite\.example\.com\.?(:[0-9]*)?$ [NC] RewriteRule ^(.*)$ https://newsite.example.net/$1 [R=301,L] 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 .htaccess file. For example, if a request for /DragonFlyBSD/HAMMER.5 were to come along, it would first be redirected internally to /d/HAMMER.5 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 302 Found status code would be issued to the client to actually redirect to the external cgi script of web-man: 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; } Please follow this link . This technique can be used by 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 refresh header: HTTP/1.1 200 OK Refresh: 0; url=https://www.example.com/ Content-Type: text/html Content-Length: 78 Please follow this link . 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: !/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 this link !" Note: Usually, the HTTP server adds the status line and the Content-Length header automatically. The 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) 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 W3C Web Content Accessibility Guidelines (1.0): Ensure user control of time-sensitive content changes, Use standard redirects: don't break the back button! and Core Techniques for Web Content Accessibility Guidelines 1.0 section 7. window.location='https://www.example.com/' 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. window.location.replace('https://www.example.com/') 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 crawlers. Please follow link . 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. Before HTML5, the same effect could be done with an HTML frame that contains the target page: Please follow link . Redirecting... "> Attempting to redirect to ">https:// . 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. In certain cases when an open redirect occurs as part of an authentication flow, the vulnerability is known as a covert redirect. When a covert redirect occurs, the attacker website can steal authentication information from the victim website. 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. Open redirects have their own CWE identifier, CWE-601. 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. ==See also== Canonical link element Clean URL Domain masking HTTP location Link rot URI normalization ==References== ==External links== Mapping URLs to Filesystem Locations - Apache HTTP Server Version 2.4 Taxonomy of JavaScript Redirection Spam (Microsoft Live Labs) Security vulnerabilities in URL Redirectors The Web Application Security Consortium Threat Classification

Text derived from https://en.wikipedia.org/w/index.php?oldid=1378664212 under CC BY-SA 4.0; modifications have been made.