URL redirection , also called URL forwarding , is a World Wide Web technique for making web pages available under more than one URL address. When a web browser tries to open a redirected URL, pages with different URLs are opened. Similarly, domain redirection or domain forwarding is when all pages in the URL domain are redirected to a different domain, such as when wikipedia.com and wikipedia.net are automatically redirected to wikipedia.org. URL redirects are for a variety of 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 website; to guide navigation in and out of the website; for privacy protection; and for unfriendly purposes such as phishing attacks or malware distributions.
Video URL redirection
Destination
There are several reasons to use URL redirects:
Similar domain names
A user may incorrectly type in a URL, for example, "example.com" and "exmaple.com". Organizations often register these "misspelled" domains and redirect them to the "right" location: example.com. The example.com and example.net addresses can redirect to a single domain, or web page, such as example.org. This technique is often used to "back up" other top-level domains (TLD) with the same name, or make it easier for the correct ".edu" or ".net" to redirect to a more familiar ".com" domain.
Moving page to new domain
Web pages can be redirected to a new domain for three reasons:
- the site may wish, or need, to change its domain name;
- the author may move their respective pages to a new domain;
- two websites may join.
With URL redirects, incoming links to expired URLs can be sent to the correct location. These links may come from other sites that have not realized that there's been a change or from the bookmarks/favorites users store in their browsers. The same is true for search engines. They often have longer/outdated domain names and links in their database and will send search users to this old URL. By using a "permanent switch" redirect to a new URL, visitors will remain on the correct page. Also, in the next search engine, search engines must detect and use newer URLs.
Noting outbound links
The access log of most web servers keeps detailed information about where visitors are coming from and how they browse hosted sites. However, they do not keep track of which visitors are left behind. This is because the visitor's browser does not need to communicate with the original server when the visitor clicks the outbound link. This information can be captured in several ways. One way involves redirecting the URL. Instead of sending visitors directly to other sites, links on the site can lead to URLs in the domain of the original website that automatically redirect to the actual target. This technique bore the negative side of the delay caused by additional requests to the original website server. Because this additional request will leave traces in the server logs, revealing which links to follow, it can also be a privacy issue. The same technique is also used by some corporate websites to implement a statement that the next content is on another site, and therefore no affiliation with the company is required. In such scenarios, displaying a warning causes an additional delay.
Alias ​​â € <â €
Web applications often include long descriptive attributes in their URLs that represent data hierarchies, command structures, transaction paths, and session information. This practice generates URLs that are aesthetically unpleasant and difficult to remember, and which may not fit the size limit of microblogging sites. The URL shortening service provides a solution to this problem by directing users to URLs longer than shorter.
Mean persistent aliases for long or changed URLs
Sometimes the page URL changes even if the content remains the same. Therefore, URL redirects can help users with bookmarks. This is routinely done on Wikipedia each time the page is renamed.
Post/Redirect/Get
Post/Redirect/Get (PRG) is a web development design pattern that prevents some duplicate form submissions, creating a more intuitive interface for user-agents (users).
Device-geo targeting and targeting
Redirects can be used effectively for targeting purposes such as device targeting or geo-targeting. Device targeting is becoming more important with the emergence of mobile clients. There are two approaches to serving mobile users: Create responsive websites or redirect to mobile website versions. If a mobile website version is offered, users with mobile clients will be automatically forwarded to the appropriate mobile content. For device targeting, client-side redirects or non-cacheable server-side redirects are used. Geo-targeting is an approach to offer localized content and automatically forward users to the localized version of the requested URL. This is useful for websites that target audiences in more than one location and/or language. Usually server side redirects are used for Geotargeting but client-side redirects may also be an option, depending on the requirements.
Manipulating search engines
Redirects have been used to manipulate search engines with unethical intent, e.g. hidden redirects or URL hijacking. The purpose of a misleading redirect is to direct search traffic to the landing page, which does not have enough ranking power on their own or that has little or no connection to the search target. This approach requires ranking for various search terms with a number of URLs that will take advantage of sneaky redirects to forward searchers to the target page. This method is experiencing a resurgence with mobile device upgrades and device targeting. URL hijacking is an off-domain redirection technique that exploits search engine handling properties for temporary redirects. If temporary redirects are found, search engines must decide whether they assign rank ratings to URLs that initiate redirects or to redirect target URLs. URLs that initiate redirects can be saved to appear in search results, as redirects show a temporary nature. Under certain circumstances it is possible to exploit this behavior by applying a temporary redirect to a good ranking URL, leading to the original URL replacement in search results by URLs that initialize redirects, therefore "stealing" the rankings. This method is usually combined with a hidden redirect to re-target the user stream from search results to the target page. Search engines have developed efficient technology to detect this kind of manipulative approach. The major search engines usually apply harsh punishment ratings on caught sites applying this technique.
Manipulating visitors
URL redirects are sometimes used as part of phishing attacks that confuse visitors about which websites they visit. Because modern browsers always display the actual URL in the address bar, the threat will decrease. However, redirects may also take you to sites that otherwise will attempt to attack in other ways. For example, redirects might take users to sites that would try to trick them into downloading antivirus software and installing some kind of Trojan instead.
Deleting references information
When the link is clicked, the browser sends it in an HTTP request field called a reference indicating the source of the link. This field is populated with the URL of the current web page, and will end up in server logs serving external links. Because sensitive pages may have sensitive URLs (for example, http://company.com/plans-for-the-next-release-of-our-product ), it's not desirable for referrer URL to exit the organization. Redirect pages that reference referrals can be embedded in all external URLs, transforming eg http://externalsite.com/page to http://redirect.company.com/http://externalsite.com/page . This technique also removes potentially more sensitive information from referrer URLs, such as session IDs, and can reduce phishing opportunities by showing end users that they are passing through a clear gateway to other sites.
Maps URL redirection
Implementation
Some types of responses to the browser will result in redirects. It varies in whether they affect HTTP headers or HTML content. The technique used usually depends on the role of the person who implements it and their access to different parts of the system. For example, web authors without control over headers may use the Refresh meta tag whereas web server administrators redirecting all pages on the site are more likely to use server configuration.
Manual redirection
The simplest technique is to ask visitors to follow links to new pages, usually using an HTML anchor such as:
This method is often used as a fall-back - if the browser does not support automatic redirects, visitors can still reach the target document by following the link.
HTTP 3xx status code
In the HTTP protocol used by the World Wide Web, redirect is a response with a status code that starts with 3 that causes the browser to display different pages. If a client encounters a redirect, he or she needs to make a number of decisions about how to handle the switch. Different status codes are used by clients to understand the purpose of redirection, how to handle caching and which query methods to use for future requests.
HTTP/1.1 defines some status codes for redirects (RFC 7231):
- 300 multiple choices (e.g. offer different languages)
- 301 permanently moved (permanent redirects from one URL to the equity of another passed link to the redirected page)
- 302 found (originally "temporary redirects" in HTTP/1.0 and popularly used for CGI scripts; replaced by 303 and 307 in HTTP/1.1 but retained for backward compatibility)
- 303 other view (forcing a GET request to a new URL even if the initial request is POST)
- 307 temporary redirects (providing new URLs for browsers to resend GET or POST requests)
- 308 permanent redirect (provides new URL for browser to resend GET or POST request)
Transferring status codes and characteristics
All of these status codes require the URL of the redirection target to be given in the Location: header of the HTTP response. 300 multiple options will usually show all options in the message body and indicate the default option in the Locations header :.
(Status code 304 not changed and 305 using proxy instead of redirection).
Sample HTTP responses for 301 redirects
The HTTP response with 301 "permanent moved" transfers looks like this:
Using server-side script for redirect
Web authors who produce HTML content usually can not make redirects using HTTP headers because these are generated automatically by web server programs when serving HTML files. The same is true even for programmers who write CGI scripts, although some servers allow scripts to add special headers (eg by enabling "non-parsed-headers"). Many web servers will generate a 3xx status code if the script issues the header row "Locations:". For example, in PHP, one can use the "header" function:
More headers may be needed to prevent caching. The programmer must ensure that the header is output before the body. It may not match the natural flow of control through the code. To help with this, some frameworks for server-side content creation can support body data. In the ASP scripting language, this can also be resolved using response.buffer = true and response.redirect "http://www.example.com/" HTTP/1.1 allows for relative URI reference or absolute URI reference. If the client relative URI reference calculates the absolute URI reference required in accordance with the rules specified in RFC 3986.
Apache mod_rewrite
The Apache HTTP Server mod_alias extension can be used to redirect a specific request. Typical configuration directives look like:
For more flexible URL redirects and redirects, Apache mod_rewrite can be used. For example, to redirect a request to a canonical domain name:
The configuration can be applied to one or all of the sites on the server via the server configuration file or to a single content directory via the .htaccess file.
nginx rewrite
Nginx has an integrated http rewriting module, which can be used to perform advanced URL processing and even web page creation (with the return ) directive. An example demonstrating the sophisticated use of the rewriting module is mdoc.su, which implements a fully deterministic URL shortening service with the help of nginx configuration language only.
For example, if a request for /DragonFlyBSD/HAMMER.5 will appear, it will first be switched internally to /d/HAMMER.5 with the first rewrite directive below ( only affect the internal state, without any HTTP replies issued to the previous client), and then with the second rewrite directive, HTTP response with 302 Status codes found will be given to the client to actually redirect to external cgi manuscript:
Refresh Meta tag and HTTP refresh header
Netscape introduces a meta refresh feature that refreshes the page after a period of time. It can specify a new URL to replace one page with another. This is supported by most web browsers. The zero second timeout will affect direct redirection. This is treated like a 301 permanent switch by Google, enabling the transfer of PageRank to the target page.
This is an example of a simple HTML document that uses this technique:
This technique can be used by web authors because the meta tags are in the document itself. Meta tags should be placed in the "head" section of the HTML file. The number "0" in this example can be replaced with another number to achieve a delay of a few seconds. The anchor in the "body" section is for users whose browsers do not support this feature.
The same effect can be achieved with the HTTP header refresh :
This response is more easily generated by the CGI program because it does not need to change the default status code.
Here is a simple CGI program that affects this redirect:
Note: Typically, HTTP servers add status rows and Content-Length headers automatically.
W3C prevents the use of meta refresh, as it does not communicate any information about the original or new source, to the browser (or search engine). The W3C Web Content Accessibility Guidelines (7.4) prevent automated page creation, as most web browsers do not allow users to disable or control the refresh rate. Some articles they have written about this issue include the W3C Web Content Accessibility Guidelines (1.0): Ensure user control over time-sensitive content changes Use standard redirects: do not damage the back button! and Core Techniques for Guidelines for Web Content Accessibility 1.0 section 7.
JavaScript redirects
JavaScript can cause redirects by setting the window.location attribute, for example:
JavaScript typically pushes the redirector site URL to the browser history. This can cause a redirect loop when the user presses the back button. With the following command, you can prevent this type of behavior.
However, HTTP headers or refresh meta tags may be preferred for security reasons and since JavaScript will not be executed by multiple browsers and many web crawlers.
Frame switch
A slightly different effect can be achieved by creating inline frames:
One major difference to the above redirection method is that for frame redirects, the browser displays the frame document URL and not the target page URL in the URL bar. This cloaking technique can be used so readers see URLs that are easier to remember or cheatly hide phishing sites as part of website spoofing.
Before HTML5, the same effect can be done with an HTML frame containing the target page:
Channel redirects
One redirect may lead to another. For example, the URL "http://wikipedia.com" (with "*.com" as domain) was first redirected to https://www.wikipedia.org/(with a domain name in.org), where you can navigate to a language-specific site. This can not be avoided if the different links in the series are served by different servers even though it should be minimized by rewriting as many URLs as possible on the server before returning them to the browser as a redirect.
Wikipedia has redirected the page to HTTPS by default since 2015.
Redirect loop
Sometimes an error can cause the page to end by redirecting back to itself, perhaps through another page, leading to an infinite diversion sequence. The browser must stop redirecting after a number of hops and display an error message.
Status HTTP/1.1 Standar:
A MUST client detects and intervenes in cycle switching (ie, "repetition of infinite looping).
Note: Previous versions of this specification recommend a maximum of five redirects ([RFC 2068], Section 10.3). Content developers should be aware that some clients may apply such fixed restrictions.
Note that URLs in order may not recur, for example: http://www.example.com/1 - & gt; http://www.example.com/2 - & gt; http://www.example.com/3...
Services
There are services that can make URL redirects on demand, without requiring technical work or access to the web server on which your site is hosted.
URL redirection service
The redirect service is an information management system, which provides an internet link that directs users to the desired content. Typical benefits for users are the use of easy-to-remember domain names, and reduction of URL length or web address. A redirect link can also be used as a permanent address for content that often changes the host, similar to the Domain Name System. Hyperlinks that involve URL redirection services are often used in spam messages directed at blogs and wikis. Thus, one way to reduce spam is to reject all edits and comments that contain hyperlinks to known URL redirection services; however, this will also remove legitimate edits and comments and may not be an effective method for reducing spam. Recently, URL redirection services have been using AJAX as an efficient and easy-to-use method for creating shortened URLs. The main disadvantage of some URL redirection services is the use of snooze pages, or frame-based ads, to generate revenue.
History
The first redirects service utilizes top-level domains (TLDs) such as ".to" (Tonga), ".at" (Austria) and ".is" (Iceland). Their goal is to create a memorable URL. The first major redirection service was V3.com which boasted 4 million users at its peak in 2000. V3.com's success was associated with having a short domain of memories 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. As the top-level domain sales prices began to drop from $ 70.00 per year to less than $ 10.00, the use of redirection services was denied. With the launch of TinyURL in 2002, a new type of redirection service was born, the URL shortening. Their goal is to make long URLs short, in order to post them on internet forums. Since 2006, with 140 character limit on the very popular Twitter service, this short URL service has been widely used.
Referrer hiding
A redirect service can hide referrers by placing an intermediate page between the page on which the link is located and its destination. While this is conceptually similar to other URL redirecting services, they serve different purposes, and they rarely try to shorten or obscure destination URLs (because the only side effect they mean is hiding referrer information and providing a clear gateway between other websites.) This type of redirect is often used to prevent potentially harmful links from getting information using referrers, such as session IDs in query strings. Many large community websites use link redirection on external links to reduce the exploit opportunities that can be used to steal account information, as well as to clarify when users leave the service, to reduce effective phishing opportunities.
Here's a simple example of such a service, written in PHP.
The above example does not check who's calling it (eg by referrer, though it can be forged). Also, it does not check the given URL. This means that bad people can link to redirection pages using URL parameters of their choice, from any page, using web server resources.
Security issues
URL redirects can be abused by attackers for phishing attacks, such as open redirect and secret redirects. "Open redirects are apps that take parameters and redirect users to parameter values ​​without any validation." "Covert Redirects is an app that takes parameters and redirects users to parameter values ​​WITHOUT SUFFICIENT validation." It was revealed in May 2014 by a mathematical doctorate student Wang Jing from Nanyang Technological University, Singapore.
See also
- Canonical link elements
- Meta canonical tag
- Domain concealment
- Rot link
- Semantic URL
- Normalize URLs
References
External links
- Map URLs to Filesystem Locations
- JavaScript Taxonomy Redirection Spam (Microsoft Live Labs)
- Security vulnerabilities in URL Redirectors Classification of Web Application Security Threats Registration
Source of the article : Wikipedia
0 Comments