Un reindirizzamento 302 manterrà la stringa del referer?

Devo reindirizzare l'utente da una pagina all'altra, ma devo mantenere la stringa di riferimento originale. Quindi, ad esempio, se iniziano su http://www.othersite.com/pageA.jsp , fai clic su un collegamento che li porta a http://www.example.com/pageB.jsp , che quindi esegue un 302 reindirizza a http://www.example.com/pageC.jsp , ho bisogno che la stringa del referer contengahttp://www.othersite.com/pageA.jsp

È questo il comportamento normale per un reindirizzamento 302? O il mio referente originale verrebbe abbandonato, a favore di http://www.example.com/pageB.jsp? Non sarebbe desiderabile.

Non so se fa differenza, ma sto lavorando in JSP e sto usando response.sendRedirect()per eseguire il reindirizzamento 302.

Devo menzionare che ho fatto un esperimento con questo, e sembra che abbia mantenuto la stringa di riferimento originale ( http://www.othersite.com/pageA.jsp) ma volevo solo assicurarmi che questo fosse il normale comportamento predefinito e non qualcosa di strano da parte mia.

Anche se attualmente sto utilizzando un reindirizzamento 302, potrei probabilmente utilizzare un reindirizzamento 301. Sai se il comportamento per i reindirizzamenti 301 è più affidabile?

La risposta breve è che non è specificato nella relativa RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 né per l'intestazione Referer né per il codice di stato 302.

La soluzione migliore è fare un test con diversi browser e vedere se c'è un comportamento di consenso.

Per cintura piena e bretelle, codifica il referrer originale nell'URL di reindirizzamento in modo da poter garantire di recuperarlo.

Non so del 302, ma oggi ho testato il 301 su alcuni browser, ecco i risultati:

SCENARIO : l'utente fa clic sul collegamento su dominioX che punta a dominioA. domainA esegue un reindirizzamento 301 a domainB.

• IE8 refererquando si atterra su domainB è: domainX (anche quando si utilizza la navigazione InPrivate e anche quando l'utente apre il collegamento in una nuova scheda)
• Safari4 refererquando si atterra su domainB è: domainX (anche quando l'utente apre il collegamento in una nuova scheda)
• FF3.6.10 refererquando si atterra su domainB è: domainX (anche quando l'utente apre il collegamento in una nuova scheda)
• Chrome5 refererquando si accede al dominioB è: dominioX (a meno che l' utente non apra i collegamenti in una nuova scheda)
• Chrome26 refererquando si atterra su domainB è: domainX (anche quando l'utente apre i collegamenti in una nuova scheda)

Buona domanda. In questo caso, l'invio del referer dipende interamente dal browser (perché al browser viene detto di fare un'altra richiesta alla nuova risorsa).

RFC 2616 rimane in silenzio sulla questione:

La risorsa richiesta risiede temporaneamente sotto un URI diverso. Poiché il reindirizzamento potrebbe essere alterato in alcune occasioni, il client DOVREBBE continuare a utilizzare l'URI della richiesta per richieste future. Questa risposta è memorizzabile nella cache solo se indicata da un campo di intestazione Cache-Control o Expires.

Non mi fiderei che il browser invii il referer giusto. Scommetto che ce n'è almeno uno che manda qualcosa di diverso dagli altri.

Soluzione

Se puoi, perché non aggiungere un ?override_referer=<old_url>parametro all'URL a cui reindirizzi e analizzare quel valore invece di HTTP_REFERER.

In questo modo puoi essere sicuro di ottenere sempre il risultato giusto e non stai perdendo nulla in termini di sicurezza: il referer può essere simulato in entrambi i casi.

Ho avuto il problema opposto: volevo che il referer fosse "pageB" ma nessuno dei browser attuali procede in questo modo ...

Quindi ho provato con un reindirizzamento HTML sulla paginaB (invece del reindirizzamento 301 o 302):

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

E il risultato è stato sorprendente:

• Il referer è pageB con Chrome
• Il referer è VUOTO con FireFox e IE!

Spero che questo possa aiutare