¿Una redirección 302 mantendrá la cadena de referencia?

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

¿Es este el comportamiento normal de una redirección 302? ¿O mi referidor original sería descartado a favor de http://www.example.com/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 la redirección 302.

Debo mencionar que hice un experimento con esto, y parece haber mantenido la cadena de referencia original ( http://www.othersite.com/pageA.jsp) pero solo quería asegurarme de que este fuera el comportamiento predeterminado normal, y no algo extraño por mi parte.

Aunque actualmente estoy usando una redirección 302, probablemente podría usar una redirección 301 en su lugar. ¿Sabe si el comportamiento de las redirecciones 301 es más confiable?

La respuesta corta es que no se especifica en el RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 relevante ni para el encabezado Referer ni para 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 completo y los tirantes, codifique la referencia original en la URL de redireccionamiento para que pueda garantizar su recuperación.

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

ESCENARIO : el usuario hace clic en el enlace de dominioX que apunta a dominioA. domainA realiza una redirección 301 a domainB.

• IE8 referercuando aterriza en dominioB es: dominioX (incluso cuando se usa la navegación InPrivate e incluso cuando el usuario abre el enlace en una nueva pestaña)
• Safari4 referercuando aterriza en el dominioB es: dominioX (incluso cuando el usuario abre el enlace en una nueva pestaña)
• FF3.6.10 referercuando aterriza en dominioB es: dominioX (incluso cuando el usuario abre el enlace en una nueva pestaña)
• Chrome5 referercuando aterriza en dominioB es: dominioX (a menos que el usuario abra enlaces en una nueva pestaña)
• Chrome26 referercuando aterriza en el dominioB es: dominioX (incluso cuando el usuario abre enlaces en una nueva pestaña)

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

RFC 2616 permanece en silencio sobre el problema:

El recurso solicitado reside temporalmente en un URI diferente. Dado que la redirección puede modificarse en ocasiones, el cliente DEBE continuar utilizando Request-URI para solicitudes futuras. Esta respuesta solo se puede almacenar en caché si se indica mediante un campo de encabezado Cache-Control o Expires.

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

Solución alterna

Si puede, ¿por qué no agregar un ?override_referer=<old_url>parámetro a la URL a la que redirige y analizar ese valor en lugar de HTTP_REFERER?

De esa manera, puede estar seguro de obtener siempre el resultado correcto y no perder nada en seguridad: el árbitro puede ser falsificado de cualquier manera.

Tuve el problema opuesto: quería que el referente fuera "pageB" pero ninguno de los navegadores actuales procede 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):

<meta http-equiv="refresh" content="0; url=pageC.jsp" />

Y el resultado fue sorprendente:

• Referer es pageB con Chrome
• ¡Referer está VACÍO con FireFox e IE!

Espero que esto pueda ayudar