Ich muss den Benutzer von einer Seite auf eine andere umleiten, aber ich muss die ursprüngliche Referenzzeichenfolge beibehalten. Wenn sie beispielsweise mit http://www.othersite.com/pageA.jsp beginnen, klicken Sie auf einen Link, der sie zu http: //www.mysite) führt. com/pageB.jsp , der dann eine 302-Umleitung zu http://www.mysite.com/pageC.jsp ausführt, muss die Referenzzeichenfolge " http : //www.othersite.com/pageA.jsp "
Ist dies das normale Verhalten bei einer 302-Umleitung? Oder würde mein ursprünglicher Referer zugunsten von " http://www.mysite.com/pageB.jsp " gelöscht werden? Das wäre nicht wünschenswert.
Ich weiß nicht, ob es einen Unterschied macht, aber ich arbeite in JSP und verwende response.sendRedirect (), um die 302-Umleitung auszuführen.
Ich sollte erwähnen, dass ich damit experimentiert habe, und es scheint, dass die ursprüngliche Referenzzeichenfolge (" http://www.othersite.com/pageA.jsp ") beibehalten wurde, aber ich wollte nur Stellen Sie sicher, dass dies das normale Standardverhalten war und nicht etwas Seltsames an meinem Ende.
Danke für deine Hilfe.
BEARBEITET ZUM HINZUFÜGEN:
Obwohl ich derzeit eine 302-Umleitung verwende, könnte ich stattdessen wahrscheinlich eine 301-Umleitung verwenden. Wissen Sie, ob das Verhalten für 301-Weiterleitungen zuverlässiger ist?
Eine kurze Antwort ist, dass sie im relevanten RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 weder für den Referer-Header noch für den 302-Status angegeben ist Code.
Am besten testen Sie mit mehreren Browsern, ob ein Konsens vorliegt.
Codieren Sie für einen vollständigen Gürtel und geschweifte Klammern den ursprünglichen Verweis in der Weiterleitungs-URL, damit Sie ihn garantiert abrufen können.
Ich kenne den 302 nicht, aber ich habe ihn heute auf einigen Browsern getestet. Hier die Ergebnisse:
SZENARIO : Benutzer klickt auf den Link auf domainX, der auf domainA verweist. domainA führt eine 301-Umleitung zu domainB durch.
referer
bei der Landung auf domainB ist: domainX (auch bei Verwendung von InPrivate-Browsing und selbst wenn der Benutzer den Link in einem neuen Tab öffnet)referer
bei der Landung auf domainB ist: domainX (auch wenn der Benutzer den Link in einem neuen Tab öffnet)referer
bei der Landung auf domainB ist: domainX (auch wenn der Benutzer den Link in einem neuen Tab öffnet)referer
bei Landung auf DomainB ist: DomainX (sofern nicht Benutzer öffnet Links in neuem Tab)referer
bei Landung auf DomainB ist: DomainX (auch wenn der Benutzer Links in neuem Tab öffnet)Gute Frage. In diesem Fall hängt das Senden des Referers vollständig vom Browser ab (da der Browser angewiesen wird, eine weitere Anforderung an die neue Ressource zu richten).
RFC 2616 schweigt sich zu dem Problem aus:
Die angeforderte Ressource befindet sich vorübergehend unter einem anderen URI. Da die Umleitung gelegentlich geändert werden kann, SOLLTE der Client den Request-URI für zukünftige Anforderungen weiterhin verwenden. Diese Antwort kann nur zwischengespeichert werden, wenn dies durch ein Cache-Control- oder Expires-Headerfeld angezeigt wird.
Ich würde dem Browser nicht vertrauen, den richtigen Referer mitzuschicken. Ich wette, es gibt mindestens einen, der etwas anderes sendet als die anderen.
Problemumgehung
Wenn dies möglich ist, fügen Sie der URL, zu der Sie umleiten, den Parameter ?override_referer=<old_url>
Hinzu, und analysieren Sie diesen Wert anstelle von HTTP_REFERER.
Auf diese Weise können Sie sicher sein, dass Sie immer das richtige Ergebnis erzielen, und Sie verlieren nichts an Sicherheit: Der Referer kann in beide Richtungen gefälscht werden.
Ich hatte das entgegengesetzte Problem: Ich wollte, dass der Referer "pageB" ist, aber keiner der aktuellen Browser geht so vor ...
Also habe ich es mit einer HTML-Umleitung auf Seite B versucht (anstelle von 301- oder 302-Umleitung):
<meta http-equiv="refresh" content="0; url=pageC.jsp" />
Und das Ergebnis war überraschend:
Hoffe das kann helfen