Ver el código de «Redirección de URL»

La '''redirección de URL''', también llamada '''reenvío de URL''', es una técnica de la [[World Wide Web]] para hacer que una [[página web]] esté disponible en más de una dirección [[Localizador de recursos uniforme|URL]]. Cuando un [[navegador web]] intenta abrir una URL que ha sido redirigida, se abre una página con una URL diferente. De manera similar, la redirección de [[Dominio de internet|dominio]] o el reenvío de dominio es cuando todas las páginas de un dominio URL se redireccionan a un dominio diferente, como cuando wikipedia.com y [http://www.wikipedia.net wikipedia.net] se redireccionan automáticamente a [http://www.wikipedia.org wikipedia.org].

La redirección de URL se realiza por varias razones:

* Por [[Acortador de URL]];
* Para evitar [[Enlace roto|enlaces rotos]] cuando se mueven páginas web;
* Permitir que varios nombres de dominio pertenecientes al mismo propietario hagan referencia a un único [[sitio web]];
* Para guiar la navegación dentro y fuera de un sitio web; 
* Para la protección de la privacidad; y
* Con fines hostiles, como ataques de [[phishing]] o distribución de [[malware]].

== Propósitos ==
Hay varias razones para utilizar la redirección de URL:

=== Nombres de dominio similares ===
Un usuario puede escribir mal una URL, por ejemplo, "ejemplo.com" y "ejemplo.com". Las organizaciones a menudo registran estos dominios "mal escritos" y los redirigen a la ubicación "correcta": ejemplo.com. Las direcciones ejemplo.com y ejemplo.net podrían redirigir a un solo dominio o página web, como ejemplo.org. Esta técnica se utiliza a menudo para "reservar" otros [[Dominio de nivel superior|dominios de nivel superior]] (DNS) con el mismo nombre, o facilitar que un verdadero ".edu" o ".net" redirija a un dominio ".com" más reconocible.

=== Mover páginas a un nuevo dominio ===
Las páginas web pueden redirigirse a un nuevo dominio por tres motivos:

* Un sitio puede desear, o necesitar, cambiar su nombre de dominio;
* Un autor puede mover sus páginas individuales a un nuevo dominio;
* Dos sitios web pueden fusionarse.

Con las redirecciones de URL, los enlaces entrantes a una URL obsoleta se pueden enviar a la ubicación correcta. Estos enlaces pueden ser de otros sitios que no se han dado cuenta de que hay un cambio o de marcadores/favoritos que los usuarios han guardado en sus navegadores. Lo mismo se aplica a los motores de búsqueda. A menudo tienen los nombres de dominio y enlaces más antiguos/obsoletos en su base de datos y enviarán a los usuarios de búsqueda a estas URL antiguas. Al utilizar un redireccionamiento "movido permanentemente" a la nueva URL, los visitantes seguirán llegando a la página correcta. Además, en la siguiente pasada del motor de búsqueda, el motor de búsqueda debería detectar y utilizar la URL más nueva.

=== Registro de enlaces salientes ===
Los registros de acceso de la mayoría de los [[Servidor web|servidores web]] guardan información detallada sobre de dónde vinieron los visitantes y cómo navegaron por el sitio alojado. Sin embargo, no registran qué enlaces dejaron los visitantes. Esto se debe a que el navegador del visitante no necesita comunicarse con el servidor original cuando el visitante hace clic en un enlace saliente. Esta información se puede capturar de varias formas. Una forma implica la redirección de URL. En lugar de enviar al visitante directamente al otro sitio, los enlaces en el sitio pueden dirigir a una URL en el dominio del sitio web original que redirige automáticamente al objetivo real. Esta técnica tiene la desventaja del retraso causado por la solicitud adicional al servidor del sitio web original. Como esta solicitud adicional dejará un rastro en el registro del servidor, revelando exactamente qué enlace se siguió, también puede ser un problema de privacidad.<ref name=":0">
{{cite journal
  | title = Google revives redirect snoopery
  | journal = Blog.anta.net
  | date = 2009-01-29
  | url = http://blog.anta.net/2009/01/29/509/
  | issn = 1797-1993
  | archiveurl=https://web.archive.org/web/20110817024348/http://blog.anta.net/2009/01/29/509/
  | archivedate=2011-08-17
}}</ref> Algunos sitios web corporativos también utilizan la misma técnica para implementar una declaración de que el contenido posterior se encuentra en otro sitio y, por lo tanto, no necesariamente está afiliado a la corporación. En tales escenarios, mostrar la advertencia provoca un retraso adicional.

=== Alias cortos para URL largas ===
{{AP|Acortador de URL}}
Las [[Aplicación web|aplicaciones web]] a menudo incluyen atributos descriptivos extensos en sus URL que representan jerarquías de datos, estructuras de comando, rutas de transacciones e información de sesión. Esta práctica da como resultado una URL que es estéticamente desagradable y difícil de recordar, y que puede no ajustarse a las limitaciones de tamaño de los sitios de [[microblogging]]. Los servicios de [[Acortador de URL|acortamiento de URL]] brindan una solución a este problema al redirigir a un usuario a una URL más larga desde una más corta.

=== Alias significativos y persistentes para URL largas o cambiantes ===
{{Véase|Enlace permanente|Localizador persistente uniforme para recursos|Enlace roto}}
A veces, la URL de una página cambia a pesar de que el contenido sigue siendo el mismo. Por lo tanto, la redirección de URL puede ayudar a los usuarios que tienen marcadores. Esto se hace habitualmente en Wikipedia cada vez que se cambia el nombre de una página.

=== Publicar/Redirigir/Obtener ===
Publicar/Redirigir/Obtener (PRO) es un patrón de diseño de [[desarrollo web]] que evita algunos envíos de [[Formulario web|formularios]] duplicados si el usuario hace clic en el botón de actualización después de enviar el formulario, creando una interfaz más intuitiva para los [[Agente de usuario|agentes de usuario]] (usuarios).

=== Orientación por dispositivo y orientación geográfica ===
Los redireccionamientos se pueden utilizar de forma eficaz con fines de segmentación, como la segmentación [[Geotargeting|geográfica]]. La segmentación por dispositivo se ha vuelto cada vez más importante con el aumento de los clientes móviles. Hay dos enfoques para atender a los usuarios de dispositivos móviles: hacer que el sitio web sea [[Diseño web adaptable|receptivo]] o redirigir a una versión de sitio web para dispositivos móviles. Si se ofrece una versión del sitio web móvil, los usuarios con clientes móviles serán automáticamente redirigidos al contenido móvil correspondiente. Para la segmentación por dispositivo, se utilizan redireccionamientos del lado del cliente o redireccionamientos del lado del servidor que no se pueden almacenar en caché. La segmentación geográfica es el enfoque para ofrecer contenido localizado y reenviar automáticamente al usuario a una versión localizada de la URL solicitada. Esto es útil para los sitios web que se dirigen al público en más de una ubicación y/o idioma. Por lo general, los redireccionamientos del lado del servidor se utilizan para la segmentación geográfica, pero los redireccionamientos del lado del cliente también pueden ser una opción, según los requisitos.<ref>{{Cite web |url=https://audisto.com/insights/guides/31/ |title=Redirects & SEO - The Total Guide |accessdate=2015-11-29 |publisher=Audisto}}</ref>

=== Manipular motores de búsqueda ===
Los redireccionamientos se han utilizado para manipular motores de búsqueda con intenciones poco éticas, por ejemplo, [[Typosquatting|secuestro de URL]]. El objetivo de las redirecciones engañosas es dirigir el tráfico de búsqueda a las páginas de destino, que no tienen suficiente poder de clasificación por sí mismas o que solo están relacionadas de forma remota o no están relacionadas con el objetivo de búsqueda. El enfoque requiere una clasificación para un rango de términos de búsqueda con una serie de URL que utilizarían redireccionamientos furtivos para reenviar al buscador a la página de destino. Este método tuvo un renacimiento con el auge de los dispositivos móviles y la orientación por dispositivo. El secuestro de URL es una técnica de redireccionamiento fuera del dominio<ref>{{cite web|url=https://www.mattcutts.com/blog/seo-advice-discussing-302-redirects/ |title=SEO advice: discussing 302 redirects |date=2006-01-04 |publisher=Matt Cutts, former Head of Google Webspam Team}}</ref> que explota la naturaleza del manejo del motor de búsqueda para redireccionamientos temporales. Si se encuentra un redireccionamiento temporal, los motores de búsqueda tienen que decidir si asignan el valor de clasificación a la URL que inicializa el redireccionamiento oa la URL de destino del redireccionamiento. La URL que inicia el redireccionamiento puede mantenerse para mostrarse en los resultados de búsqueda, ya que el redireccionamiento indica una naturaleza temporal. En determinadas circunstancias, fue posible explotar este comportamiento aplicando redireccionamientos temporales a URL bien posicionadas, lo que llevó a un reemplazo de la URL original en los resultados de búsqueda por la URL que inicializó la redirección, "robando" la clasificación. Este método generalmente se combinaba con redireccionamientos furtivos para redirigir el flujo de usuarios de los resultados de búsqueda a una página de destino. Los motores de búsqueda han desarrollado tecnologías eficientes para detectar este tipo de enfoques manipuladores. Los principales motores de búsqueda suelen aplicar severas sanciones de clasificación en los sitios que son atrapados aplicando técnicas como estas.<ref>{{cite web|url=https://support.google.com/webmasters/answer/2721217?hl=en |title=Sneaky Redirects |date=2015-12-03 |publisher=Google Webmaster Guidelines}}</ref>

=== Manipular visitantes ===
La redirección de URL se utiliza a veces como parte de los ataques de [[phishing]] que confunden a los visitantes sobre qué sitio web están visitando.<ref>{{cite web|url=https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet |title=Unvalidated Redirects and Forwards Cheat Sheet |date=2014-08-21 |publisher=Open Web Application Security Project (OWASP)}}</ref> Debido a que los navegadores modernos siempre muestran la URL real en la [[barra de direcciones]], la amenaza se reduce. Sin embargo, los redireccionamientos también pueden llevarlo a sitios que de otra manera intentarán atacar de otras formas. Por ejemplo, una redirección podría llevar a un usuario a un sitio que intentaría engañarlo para que descargue software [[antivirus]] e instale un [[Troyano (informática)|troyano]] de algún tipo.

=== Eliminar información del Referer ===
Cuando se hace clic en un enlace, el navegador envía junto con la [[Protocolo de transferencia de hipertexto|solicitud HTTP]] un campo llamado [[Referer]] que indica la fuente del enlace. Este campo se completa con la URL de la página web actual y terminará en los [[Registro del servidor|registros del servidor]] que sirve el enlace externo. Dado que las páginas sensibles pueden tener URL sensibles (por ejemplo, <code><nowiki>http://company.com/plans-for-the-next-release-of-our-product</nowiki></code>), no es conveniente que la URL de <code>referer</code> abandone la organización. Una página de redirección que realiza la [[Referer|ocultación de referer]] podría estar incrustada en todas las URL externas, transformando, por ejemplo <code><nowiki>http://externalsite.com/page</nowiki></code> dentro <code><nowiki>http://redirect.company.com/http://externalsite.com/page</nowiki></code>. Esta técnica también elimina otra información potencialmente confidencial de la URL de referencia, como el [[Identificador de sesión|ID de sesión]], y puede reducir la posibilidad de [[phishing]] al indicar al usuario final que pasó una [[puerta de enlace]] clara a otro sitio.

== Implementación ==
Varios tipos diferentes de respuesta al navegador resultarán en una redirección. Estos varían en cuanto a si afectan a las [[Anexo:Cabeceras HTTP|cabeceras HTTP]] o al contenido HTML. Las técnicas utilizadas normalmente dependen del rol de la persona que las implementa y su acceso a diferentes partes del sistema. Por ejemplo, un autor web sin control sobre los encabezados puede usar una metaetiqueta Actualizar, mientras que un administrador del servidor web que redirige todas las páginas de un sitio es más probable que use la configuración del servidor.

=== Redireccionamiento manual ===
La técnica más simple es pedirle al visitante que siga un enlace a la nueva página, generalmente usando un ancla HTML como:

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

Este método se utiliza a menudo como alternativa: si el navegador no admite la redirección automática, el visitante aún puede llegar al documento de destino siguiendo el enlace.

=== Códigos de estado HTTP 3xx ===
En el [[Protocolo de comunicaciones|protocolo]] [[Protocolo de transferencia de hipertexto|HTTP]] utilizado por la [[World Wide Web]], una '''redirección''' es una respuesta con un [[Anexo:Códigos de estado HTTP|código de estado]] que comienza con 3 y que hace que un navegador muestre una página diferente. Si un cliente encuentra un redireccionamiento, debe tomar una serie de decisiones sobre cómo manejar el redireccionamiento. Los clientes utilizan diferentes códigos de estado para comprender el propósito de la redirección, cómo manejar el almacenamiento en caché y qué método de solicitud usar para la solicitud posterior.

HTTP/1.1 define varios códigos de estado para la redirección (RFC 7231):

* [[Anexo:Códigos de estado HTTP|300 opciones múltiples]] (por ejemplo, ofrecer diferentes idiomas)
* [[HTTP 301|301 movido permanentemente]] (redirige permanentemente de una URL a otra pasando la equidad del enlace a la página redirigida)
* 302 encontrado (originalmente "redireccionamiento temporal" en HTTP/1.0 y popularmente usado para scripts CGI; reemplazado por 303 y 307 en HTTP/1.1 pero preservado para compatibilidad con versiones anteriores)
* 303 ver otro (fuerza una solicitud GET a la nueva URL incluso si la solicitud original fue POST)
* [[Anexo:Códigos de estado HTTP|307 redireccionamiento temporal]] (proporciona una nueva URL para que el navegador vuelva a enviar una solicitud GET o POST)
* [[Anexo:Códigos de estado HTTP|308 redirección permanente]] (proporciona una nueva URL para que el navegador vuelva a enviar una solicitud GET o POST)

==== Redirigir códigos de estado y características ====
{| class="wikitable"
|-
! Código de Estado HTTP !! Versión HTTP !! Temporalmente / Permanentemente !! Caché !! Método de Solicitud Solicitud Posterior
|-
| 301 || HTTP/1.0 || Permanentemente || {{Sí}} || GET/POST puede cambiar 
|-
| 302 || HTTP/1.0 || Temporalmente || {{No}} || GET/POST puede cambiar
|-
| 303 || HTTP/1.1 || Temporalmente || {{No}} || Siempre GET
|-
| 307 || HTTP/1.1 || Temporalmente || {{No}} || Puede que no cambie
|-
| 308 || HTTP/1.1 || Permanentemente || {{Sí}} || Puede que no cambie
|-
|}<ref>{{Cite web |url=https://audisto.com/insights/guides/31/ |title=Redirects & SEO - The Complete Guide |accessdate=2015-11-29 |publisher=Audisto}}</ref>

Todos estos códigos de estado requieren que se proporcione la URL del destino de la redirección en el encabezado Ubicación: de la respuesta HTTP. Las 300 opciones múltiples generalmente enumerarán todas las opciones en el cuerpo del mensaje y mostrarán la opción predeterminada en la Ubicación: encabezado.

(Los códigos de estado [[Anexo:Códigos de estado HTTP|304 no modificados]] y [[Anexo:Códigos de estado HTTP|305 usan proxy]] no son redireccionamientos).

==== Ejemplo de respuesta HTTP para un redireccionamiento 301 ====
Una respuesta [[Protocolo de transferencia de hipertexto|HTTP]] con el redireccionamiento 301 "movido permanentemente" se ve así:

<syntaxhighlight lang="http">
HTTP/1.1 301 Moved Permanently
Location: http://www.example.org/
Content-Type: text/html
Content-Length: 174

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

==== Usar secuencias de comandos del lado del servidor para la redirección ====
Los autores web que producen contenido HTML generalmente no pueden crear redireccionamientos utilizando encabezados HTTP, ya que estos son generados automáticamente por el programa del servidor web cuando se entrega un archivo HTML. Lo mismo suele ser cierto incluso para los programadores que escriben scripts CGI, aunque algunos servidores permiten que los scripts agreguen encabezados personalizados (por ejemplo, habilitando "encabezados no analizados"). Muchos servidores web generarán un código de estado 3xx si un script genera una línea de encabezado "Ubicación:". Por ejemplo, en [[PHP]], se puede usar la función "encabezado":

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

Es posible que se requieran más encabezados para evitar el almacenamiento en caché.<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 |archiveurl=https://web.archive.org/web/20121012042703/http://www.websitefactors.co.uk/php/2011/05/php-redirects-302-to-301-rock-solid-solution |archivedate=2012-10-12}}</ref> El programador debe asegurarse de que los encabezados se emitan antes que el cuerpo. Es posible que esto no encaje fácilmente con el flujo natural de control a través del código. Para ayudar con esto, algunos marcos para la generación de contenido del lado del servidor pueden almacenar los datos del cuerpo. En el lenguaje de [[Active Server Pages|secuencias de comandos ASP]], esto también se puede lograr utilizando <code>response.buffer=true</code> y <code>response.redirect <nowiki>"http://www.example.com/"</nowiki></code> HTTP / 1.1 permite una referencia URI relativa o una referencia URI absoluta.<ref>{{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> Si la referencia de URI es relativa, el cliente calcula la referencia de URI absoluta requerida de acuerdo con las reglas definidas en RFC 3986.<ref>{{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>

==== Servidor HTTP Apache mod_rewrite ====
La extensión mod_alias del [[Servidor HTTP Apache]] se puede utilizar para redirigir determinadas solicitudes. Las directivas de configuración típicas se ven así:

<syntaxhighlight lang="apache">
Redirect permanent /oldpage.html http://www.example.com/newpage.html
Redirect 301 /oldpage.html http://www.example.com/newpage.html
</syntaxhighlight>

Para una reescritura y redirección de URL más flexibles, se puede utilizar Apache mod_rewrite. Por ejemplo, para redirigir una solicitud a un nombre de dominio canónico:

<syntaxhighlight lang="apache">
RewriteEngine on
RewriteCond %{HTTP_HOST} ^([^.:]+\.)*oldsite\.example\.com\.?(:[0-9]*)?$ [NC]
RewriteRule ^(.*)$ http://newsite.example.net/$1 [R=301,L]
</syntaxhighlight>

Esta configuración se puede aplicar a uno o todos los sitios del servidor a través de los archivos de configuración del servidor oa un único directorio de contenido a través de un archivo <code>[[.htaccess]]</code>.

==== Nginx reescrito ====
[[Nginx]] tiene un módulo de reescritura http integrado,<ref>{{cite web|url=http://nginx.org/r/rewrite |title=Module ngx_http_rewrite_module - rewrite |publisher=nginx.org |accessdate=2014-12-24}}</ref> que se puede utilizar para realizar un procesamiento avanzado de URL e incluso la generación de páginas web (con la directiva de retorno). Un ejemplo que muestra el uso tan avanzado del módulo de reescritura es [http://mdoc.su/ mdoc.su], que implementa un servicio de [[Acortador de URL|acortamiento de URL]] determinista completamente con la ayuda del lenguaje de configuración nginx solamente.<ref>{{cite mailing list |date=2013-02-18 |url=http://mailman.nginx.org/pipermail/nginx/2013-February/037592.html |mailinglist=nginx@nginx.org |title=A dynamic web-site written wholly in nginx.conf? Introducing mdoc.su! |first=Constantine A. |last=Murenin |accessdate=2014-12-24}}</ref><ref>{{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=2013-02-23 |accessdate=2014-12-25}}</ref>

Por ejemplo, si llegara una solicitud para <tt>[https://www.dragonflybsd.org/cgi/web-man?command=HAMMER&section=5 /DragonFlyBSD/HAMMER.5]</tt>, primero se redirigiría internamente a /d/HAMMER.5 con la primera directiva de reescritura a continuación (solo afecta al estado interno, sin ninguna respuesta HTTP emitida al cliente todavía), y luego con la segunda directiva de reescritura, se enviaría al cliente una [[Protocolo de transferencia de hipertexto|respuesta HTTP]] con un código de estado 302 Encontrado para redirigirlo al [[Interfaz de entrada común|script cgi]] externo de web-[[Man (Unix)|man]]:<ref>{{cite web |url=http://nginx.conf.mdoc.su/mdoc.su.nginx.conf |title=mdoc.su.nginx.conf |first=Constantine A. |last=Murenin |date=2013-02-23 |accessdate=2014-12-25}}</ref>

<syntaxhighlight lang="nginx">
	location /DragonFly {
		rewrite	^/DragonFly(BSD)?([,/].*)?$	/d$2	last;
	}
	location /d {
		set	$db	"http://leaf.dragonflybsd.org/cgi/web-man?command=";
		set	$ds	"&section=";
		rewrite	^/./([^/]+)\.([1-9])$		$db$1$ds$2	redirect;
	}
</syntaxhighlight>

=== Actualizar metaetiqueta y encabezado de actualización HTTP ===
[[Netscape Communications Corporation|Netscape]] introdujo la función de actualización de meta que actualiza una página después de un cierto período de tiempo. Esto puede especificar una nueva URL para reemplazar una página por otra. Esto es compatible con la mayoría de los navegadores web.<ref>{{cite web|url=https://www.w3schools.com/tags/tag_meta.asp|title=HTML meta tag|website=www.w3schools.com}}</ref><ref>{{cite web|url=http://wp.netscape.com/assist/net_sites/pushpull.html|title=An Exploration of Dynamic Documents|date=2002-08-02|archiveurl=https://web.archive.org/web/20020802170847/http://wp.netscape.com/assist/net_sites/pushpull.html|archivedate=2002-08-02}}</ref> Un tiempo de espera de cero segundos produce una redirección inmediata. Google lo trata como un redireccionamiento permanente 301, lo que permite la transferencia de [[PageRank]] a la página de destino.<ref>[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>

Este es un ejemplo de un documento HTML simple que utiliza esta técnica:

<syntaxhighlight lang="html">
<html>
<head>
  <meta http-equiv="Refresh" content="0; url=http://www.example.com/" />
</head>
<body>
  <p>Please follow <a href="http://www.example.com/">this link</a>.</p>
</body>
</html>
</syntaxhighlight>

Los [[Diseño web|autores web]] pueden utilizar esta técnica porque la metaetiqueta se encuentra dentro del propio documento. La metaetiqueta debe colocarse en la sección "encabezado" del archivo HTML. El número "0" en este ejemplo puede reemplazarse por otro número para lograr un retraso de esa cantidad de segundos. El ancla en la sección "cuerpo" es para usuarios cuyos navegadores no admiten esta función.

El mismo efecto se puede lograr con un encabezado de <code>refresh</code> HTTP:

<syntaxhighlight lang="http">
HTTP/1.1 200 OK
Refresh: 0; url=http://www.example.com/
Content-Type: text/html
Content-Length: 78

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

Esta respuesta es más fácil de generar mediante programas CGI porque no es necesario cambiar el código de estado predeterminado. 

Aquí hay un programa CGI simple que efectúa esta redirección:

<syntaxhighlight lang="perl">
#!/usr/bin/perl
print "Refresh: 0; url=http://www.example.com/\r\n";
print "Content-Type: text/html\r\n";
print "\r\n";
print "Please follow <a href=\"http://www.example.com/\">this link</a>!"
</syntaxhighlight>

Nota: Por lo general, el servidor HTTP agrega la línea de estado y el encabezado Content-Length automáticamente.

El [[World Wide Web Consortium|W3C]] desaconseja el uso de la meta actualización, ya que no comunica ninguna información sobre el recurso original o nuevo al navegador (o motor de búsqueda). Las Pautas de accesibilidad al contenido web del W3C (7.4)<ref>{{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> desalientan la creación de páginas que se actualizan automáticamente, ya que la mayoría de los navegadores web no permiten que el usuario deshabilite o controle la frecuencia de actualización. Algunos de los artículos que han escrito sobre el tema incluyen las [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-movement Pautas de Accesibilidad al Contenido Web del W3C (1.0): Garantice el Control del Usuario de los Cambios de Contenido Urgentes], Usar redireccionamientos estándar: ¡no rompa el botón de retroceso!<ref>{{cite web|url=http://www.w3.org/QA/Tips/reback|title=Use standard redirects|first=the QA|last=Team|website=www.w3.org}}</ref> y Técnicas Básicas para las Directrices de Accesibilidad al Contenido Web 1.0 Sección 7.<ref>{{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>

=== Redireccionamientos JavaScript ===
[[JavaScript]] puede causar una redirección configurando el atributo <code>window.location</code>, por ejemplo:

<syntaxhighlight lang="javascript">
window.location='http://www.example.com/'
</syntaxhighlight>

Normalmente, JavaScript inserta la [[Localizador de recursos uniforme|URL]] del sitio redirector en el historial del navegador. Puede causar bucles de redirección cuando los usuarios presionan el botón Atrás. Con el siguiente comando puedes prevenir este tipo de comportamiento.<ref>{{cite web|url=http://insider.zone/tools/client-side-url-redirect-generator/|title=Cross-browser client side URL redirect generator|publisher=Insider Zone|fechaacceso=8 de noviembre de 2020|fechaarchivo=26 de julio de 2020|urlarchivo=https://web.archive.org/web/20200726044044/http://insider.zone/tools/client-side-url-redirect-generator/|deadurl=yes}}</ref>

<syntaxhighlight lang="javascript">
window.location.replace('http://www.example.com/')
</syntaxhighlight>

Sin embargo, los encabezados HTTP o la metaetiqueta de actualización pueden ser preferidos por razones de seguridad y porque algunos navegadores y muchos [[Araña web|rastreadores web]] no ejecutarán JavaScript.

=== Redirecciones de marcos ===
Se puede lograr un efecto ligeramente diferente creando un marco en línea:

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

Una diferencia principal con los métodos de redireccionamiento anteriores es que para un redireccionamiento de marco, el navegador muestra la URL del documento del marco y no la URL de la página de destino en la barra de URL. Esta ''técnica'' de encubrimiento puede usarse para que el lector vea una URL más memorable o para ocultar de manera fraudulenta un sitio de [[phishing]] como parte de la [[Web spoofing|suplantación de sitios web]].<ref>Aaron Emigh (19 January 2005). [http://www.sfbay-infragard.org/Documents/phishing-sfectf-report.pdf "Anti-Phishing Technology"] {{Wayback|url=http://www.sfbay-infragard.org/Documents/phishing-sfectf-report.pdf |date=20070927171420 }} (PDF). Radix Labs.</ref>

Antes de HTML5,<ref>{{cite web|url=https://www.w3.org/TR/html5/obsolete.html|title=HTML 5.2: 11. Obsolete features|website=www.w3.org}}</ref> se podía hacer el mismo efecto con un marco HTML que contiene la página de destino:

<syntaxhighlight lang="html">
<frameset rows="100%">
  <frame src="http://www.example.com/">
  <noframes>
    <body>Please follow <a href="http://www.example.com/">link</a>.</body>
  </noframes>
</frameset>
</syntaxhighlight>

=== Cadenas de redireccionamiento ===
Un redireccionamiento puede llevar a otro. Por ejemplo, la URL "http://wikipedia.com" (con "* .com" como dominio) se redirige primero a https://www.wikipedia.org/ (con el nombre de dominio en .org), donde puede navegue hasta el [https://en.wikipedia.org/ sitio específico del idioma]. Esto es inevitable si los diferentes enlaces de la cadena son atendidos por diferentes servidores, aunque debe minimizarse ''reescribiendo'' la URL tanto como sea posible en el servidor antes de devolverla al navegador como una redirección.

Wikipedia ha redirigido sus páginas a HTTPS de forma predeterminada desde 2015.<ref>[https://venturebeat.com/2015/06/12/wikipedia-to-start-using-secure-https-by-default-for-all-users/ Wikipedia to start using secure HTTPS by default for all users] VentureBeat article, 12 June 2015</ref>

=== Redirigir bucles ===
A veces, un error puede hacer que una página termine redirigiéndose a sí misma, posiblemente a través de otras páginas, dando lugar a una secuencia infinita de redireccionamientos. Los navegadores deberían dejar de redireccionar después de una cierta cantidad de saltos y mostrar un mensaje de error.

El estándar HTTP/1.1 establece:<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>

<blockquote>
Un cliente ''DEBE'' detectar e intervenir en redirecciones cíclicas (es decir, bucles de redirección "infinitos").

Nota: Una versión anterior de esta especificación recomendaba un máximo de cinco redirecciones ([RFC 2068], Sección 10.3). Los desarrolladores de contenido deben ser conscientes de que algunos clientes pueden implementar una limitación tan fija.
</blockquote>

== Servicios ==
Existen servicios que pueden realizar la redirección de URL bajo demanda, sin necesidad de trabajo técnico o acceso al servidor web en el que está alojado su sitio.

=== Servicios de redireccionamiento de URL ===
Un '''servicio de redireccionamiento''' es un sistema de gestión de información, que proporciona un enlace de Internet que redirige a los usuarios al contenido deseado. El beneficio típico para el usuario es el uso de un nombre de dominio memorable y una reducción en la longitud de la URL o dirección web. Un enlace de redireccionamiento también se puede utilizar como dirección permanente para el contenido que cambia de host con frecuencia, de manera similar al [[sistema de nombres de dominio]]. Los hipervínculos que incluyen servicios de redireccionamiento de URL se utilizan con frecuencia en mensajes de spam dirigidos a blogs y wikis. Por lo tanto, una forma de reducir el spam es rechazar todas las ediciones y comentarios que contengan hipervínculos a servicios de redirección de URL conocidos; sin embargo, esto también eliminará las ediciones y los comentarios legítimos y puede que no sea un método eficaz para reducir el spam. Recientemente, los servicios de redirección de URL han adoptado [[AJAX]] como un método eficaz y fácil de usar para crear URL abreviadas. Un gran inconveniente de algunos servicios de redireccionamiento de URL es el uso de páginas de retraso, o publicidad basada en marcos, para generar ingresos.

==== Historia ====
Los primeros servicios de redireccionamiento aprovecharon los [[Dominio de nivel superior|dominios de nivel superior]] (DNS) como "[[.to]]" (Tonga), "[[.at]]" (Austria) y "[[.is]]" (Islandia). Su objetivo era crear URL memorables. El primer servicio de redireccionamiento convencional fue V3.com, que contaba con 4 millones de usuarios en su punto máximo en 2000. El éxito de V3.com se atribuyó a tener una amplia variedad de dominios breves y memorables, incluidos "r.im", "go.to", "i .am","come.to" y "start.at". V3.com fue adquirida por FortuneCity.com, una gran empresa de [[alojamiento web]] gratuito, a principios de 1999.<ref>{{cite news|url=http://news.bbc.co.uk/2/hi/technology/6991719.stm|work=BBC News|title=Net gains for tiny Pacific nation|date=2007-09-14|accessdate=27 May 2010|archiveurl=https://web.archive.org/web/20140512232450/http://news.bbc.co.uk/2/hi/technology/6991719.stm|archivedate=12 May 2014}}</ref> A medida que el precio de venta de los dominios de nivel superior comenzó a caer de $70.00 por año a menos de $10.00, el uso de los servicios de redireccionamiento disminuyó. Con el lanzamiento de [[TinyURL]] en 2002, nació un nuevo tipo de servicio de redireccionamiento, el [[Acortador de URL|acortamiento de URL]]. Su objetivo era acortar las URL largas para poder publicarlas en foros de Internet. Desde 2006, con el límite de 140 caracteres en el extremadamente popular servicio de [[Twitter]], estos servicios de URL cortos se han utilizado mucho.

=== Enmascaramiento de referente ===
Los servicios de redirección pueden ocultar la [[Referer|referencia]] colocando una página intermedia entre la página en la que se encuentra el enlace y su destino. Aunque estos son conceptualmente similares a otros servicios de redireccionamiento de URL, tienen un propósito diferente y rara vez intentan acortar u ofuscar la URL de destino (ya que su único efecto secundario previsto es ocultar la información de referencia y proporcionar una puerta de enlace clara entre otros sitios web. ) Este tipo de redireccionamiento se utiliza a menudo para evitar que los enlaces potencialmente maliciosos obtengan información utilizando la referencia, por ejemplo, un [[Identificador de sesión|ID de sesión]] en la cadena de consulta. Muchos sitios web de grandes comunidades utilizan la redirección de enlaces en enlaces externos para disminuir la posibilidad de un [[exploit]] que podría usarse para robar información de la cuenta, así como para dejar en claro cuándo un usuario abandona un servicio, para disminuir la posibilidad de un [[phishing]] efectivo. 

Aquí hay un ejemplo simplista de dicho servicio, escrito en 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>

El ejemplo anterior no verifica quién lo llamó (por ejemplo, por referencia, aunque eso podría ser falsificado). Además, no comprueba la URL proporcionada. Esto significa que una persona malintencionada podría enlazar a la página de redireccionamiento utilizando un parámetro de URL de su propia selección, desde cualquier página, que utilice los recursos del servidor web.

== Temas de seguridad ==
Los atacantes pueden abusar de la redirección de URL para ataques de [[phishing]], como la redirección abierta y la redirección encubierta. "Una redirección abierta es una aplicación que toma un parámetro y redirige a un usuario al valor del parámetro sin ninguna validación".<ref name="Open_Redirect">{{cite web | url=https://www.owasp.org/index.php/Open_redirect | title=Open Redirect |publisher= OWASP |date=2014-03-16 | accessdate=2014-12-21}}</ref> "La redirección encubierta es una aplicación que toma un parámetro y redirige a un usuario al valor del parámetro SIN SUFICIENTE validación".<ref name="Covert_Redirect">{{cite web | url=http://tetraph.com/covert_redirect/ | title=Covert Redirect | publisher=Tetraph | date=1 May 2014 | accessdate=2014-12-21 | fechaarchivo=10 de marzo de 2016 | urlarchivo=https://web.archive.org/web/20160310005903/http://tetraph.com/covert_redirect/ | deadurl=yes }}</ref> Fue revelado en mayo de 2014 por un estudiante de doctorado en matemáticas Wang Jing de la Universidad Tecnológica de Nanyang, Singapur.<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 | accessdate=2014-12-21}}</ref>

== Véase también ==
* [[Enlace roto]]
* [[URL semántica]]

== Referencias ==
{{Listaref|2}}

== Enlaces externos ==
* [http://httpd.apache.org/docs/1.3/urlmapping.html Asignación de URL a Ubicaciones del Sistema de Archivos] {{Wayback|url=http://httpd.apache.org/docs/1.3/urlmapping.html |date=20200805201026 }}
* [http://www2007.org/workshops/paper_115.pdf Taxonomía del Spam de Redireccionamiento de JavaScript] (Microsoft Live Labs)
* [http://projects.webappsec.org/URL-Redirector-Abuse Vulnerabilidades de Seguridad en Redirectores de URL] Clasificación de Amenazas del Consorcio de Seguridad de Aplicaciones Web

{{Control de autoridades}}
[[Categoría:Localizador de recursos uniforme]]
[[Categoría:Búsqueda en internet]]