¿Una redirección 302 mantendrá la cadena del referer?

Necesito redirigir al usuario de una página a otra, pero necesito mantener la cadena del referer original. Entonces, por ejemplo, si comienzan en http://www.othersite.com/pageA.jsp , haga clic en un enlace que los lleve a http://www.mysite.com/pageB.jsp , que luego ejecutará un 302 redireccionar a http://www.mysite.com/pageC.jsp , necesito que la cadena del referer contenga ” http://www.othersite.com/pageA.jsp ”

¿Es este el comportamiento normal de un redireccionamiento 302? ¿O se eliminaría mi referencia original a favor de ” http://www.misitio.es/pageB.jsp “? Eso no sería deseable.

No sé si hace alguna diferencia, pero estoy trabajando en JSP, y estoy usando response.sendRedirect () para ejecutar el redireccionamiento 302.

Debo mencionar que hice un experimento con esto, y que parece haber conservado la cadena del referer original (” http://www.othersite.com/pageA.jsp “), pero solo quería asegurarme de que este era el valor predeterminado normal. comportamiento, y no algo raro en mi extremo.

Gracias por tu ayuda.

EDITADO PARA AGREGAR:

Aunque actualmente estoy usando un redireccionamiento 302, probablemente podría usar un redireccionamiento 301 en su lugar. ¿Sabes si el comportamiento de los redireccionamientos 301 es más confiable?

La respuesta corta es que no está especificada en el RFC 2616 relevante http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 ya sea para el encabezado Referer o el código de estado 302.

Su mejor opción es hacer una prueba con varios navegadores y ver si hay un comportamiento de consenso.

Para el cinturón lleno y llaves, codifique la referencia original en la URL de redirección para que pueda garantizar que la recupere.

No sé sobre el 302, pero probé el 301 en algunos navegadores hoy, aquí los resultados:

ESCENARIO : el usuario hace clic en el enlace en domainX que apunta a domainA. domainA hace una redirección 301 a domainB.

  • IE8 referer al aterrizar en domainB es: domainX (incluso cuando se utiliza la navegación InPrivate e incluso cuando el usuario abre el enlace en la nueva pestaña)
  • El referenciador de Safari4 al aterrizar en el dominio B es: domainX (incluso cuando el usuario abre el enlace en una pestaña nueva)
  • Referer FF3.6.10 al aterrizar en domainB es: domainX (incluso cuando el usuario abre el enlace en la nueva pestaña)
  • El referenciador de Chrome5 al aterrizar en el dominioB es: domainX (a menos que el usuario abra enlaces en una pestaña nueva)
  • El referenciador de Chrome26 al aterrizar en el dominioB es: domainX (incluso cuando el usuario abre enlaces en una pestaña nueva)

Buena pregunta. En este caso, el envío del referer depende completamente del navegador (porque se le dice al navegador que haga otra solicitud al nuevo recurso).

RFC 2616 guarda silencio sobre el problema:

El recurso solicitado reside temporalmente bajo un URI diferente. Como la redirección podría verse alterada ocasionalmente, el cliente DEBERÍA continuar utilizando el URI de solicitud para futuras solicitudes. Esta respuesta solo se puede almacenar en caché si está indicada por un campo de encabezado Cache-Control o Expires.

No confiaría en que el navegador envíe el referer adecuado. Apuesto a que hay al menos uno que envía algo diferente a los demás.

Solución

Si puede, ¿por qué no agrega un parámetro ?override_referer= a la URL a la que redirecciona, y analiza ese valor en lugar de HTTP_REFERER.

De esta manera, puede estar seguro de obtener siempre el resultado correcto, y no está perdiendo nada en seguridad: el remitente puede ser falso de cualquier manera.

Tuve el problema opuesto: quería que el referidor fuera “página B”, pero ninguno de los navegadores no funciona de esta manera …

Así que probé con una redirección HTML en la página B (en lugar de la redirección 301 o 302):

  

Y el resultado fue sorprendente:

  • Referer es la página B con Chrome
  • ¡Referer está VACÍO con FireFox y IE!

Espero que esto pueda ayudar