Liệu chuyển hướng 302 có duy trì chuỗi giới thiệu không?

Tôi cần chuyển hướng người dùng từ trang này sang trang khác, nhưng tôi cần duy trì chuỗi giới thiệu ban đầu. Vì vậy, ví dụ: nếu họ bắt đầu trên http://www.othersite.com/pageA.jsp , hãy nhấp vào liên kết đưa họ đến http://www.example.com/pageB.jsp , sau đó thực thi 302 chuyển hướng đến http://www.example.com/pageC.jsp , tôi cần chuỗi giới thiệu để chứahttp://www.othersite.com/pageA.jsp

Đây có phải là hành vi bình thường đối với chuyển hướng 302 không? Hay người giới thiệu ban đầu của tôi sẽ bị loại bỏ, ủng hộ http://www.example.com/pageB.jsp? Điều đó sẽ không được mong muốn.

Tôi không biết liệu nó có tạo ra sự khác biệt nào không, nhưng tôi đang làm việc trong JSP và tôi đang sử dụng response.sendRedirect()để thực hiện chuyển hướng 302.

Tôi nên đề cập rằng tôi đã thực hiện một thử nghiệm với điều này và có vẻ như nó đã giữ chuỗi giới thiệu ban đầu ( http://www.othersite.com/pageA.jsp) nhưng tôi chỉ muốn đảm bảo rằng đây là hành vi mặc định bình thường và không phải là điều gì đó kỳ lạ về phía tôi.

Mặc dù tôi hiện đang sử dụng chuyển hướng 302, nhưng tôi có thể sử dụng chuyển hướng 301 để thay thế. Bạn có biết liệu hành vi của chuyển hướng 301 có đáng tin cậy hơn không?

Câu trả lời ngắn gọn là nó không được chỉ định trong RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 có liên quan cho tiêu đề Người giới thiệu hoặc mã trạng thái 302.

Đặt cược tốt nhất của bạn là thực hiện thử nghiệm với một số trình duyệt và xem liệu có hành vi đồng thuận hay không.

Đối với dây đai và nẹp đầy đủ, hãy mã hóa liên kết giới thiệu ban đầu trong URL chuyển hướng để bạn có thể đảm bảo truy xuất nó.

Tôi không biết về 302, nhưng tôi đã thử nghiệm 301 trên một số trình duyệt hôm nay, đây là kết quả:

SCENARIO : người dùng nhấp vào liên kết trên domainX trỏ đến domainA. domainA thực hiện chuyển hướng 301 đến domainB.

• IE8 refererkhi hạ cánh trên domainB là: domainX (ngay cả khi sử dụng duyệt InPrivate và ngay cả khi người dùng mở liên kết trong tab mới)
• Safari4 refererkhi hạ cánh trên domainB là: domainX (ngay cả khi người dùng mở liên kết trong tab mới)
• FF3.6.10 refererkhi hạ cánh trên domainB là: domainX (ngay cả khi người dùng mở liên kết trong tab mới)
• Chrome5 refererkhi hạ cánh trên domainB là: domainX ( trừ khi người dùng mở liên kết trong tab mới)
• Chrome26 refererkhi hạ cánh trên domainB là: domainX (ngay cả khi người dùng mở liên kết trong tab mới)

Câu hỏi hay. Trong trường hợp này, việc gửi tham chiếu phụ thuộc hoàn toàn vào trình duyệt (vì trình duyệt được yêu cầu thực hiện một yêu cầu khác đối với tài nguyên mới).

RFC 2616 vẫn giữ im lặng về vấn đề này:

Tài nguyên được yêu cầu tạm thời nằm trong một URI khác. Vì đôi khi chuyển hướng có thể bị thay đổi, khách hàng NÊN tiếp tục sử dụng URI Yêu cầu cho các yêu cầu trong tương lai. Phản hồi này chỉ có thể lưu vào bộ nhớ cache nếu được chỉ ra bởi trường tiêu đề Cache-Control hoặc Expires.

Tôi sẽ không tin tưởng trình duyệt gửi người giới thiệu phù hợp. Tôi cá là có ít nhất một cái gửi thứ gì đó khác với những cái khác.

Cách giải quyết

Nếu bạn có thể, tại sao không thêm một ?override_referer=<old_url>tham số vào URL bạn chuyển hướng đến và phân tích cú pháp giá trị đó thay vì HTTP_REFERER.

Bằng cách đó, bạn có thể chắc chắn luôn nhận được kết quả phù hợp và bạn không mất bất cứ điều gì về bảo mật: Người giới thiệu có thể bị giả mạo theo cả hai cách.

Tôi gặp sự cố phức tạp: Tôi muốn giới thiệu đó là "pageB" nhưng không có trình duyệt nào trong số trình duyệt xử lý theo cách này ...

Vì vậy, tôi đã thử chuyển hướng HTML trên pageB (thay vì chuyển hướng 301 hoặc 302):

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

Và kết quả thật đáng ngạc nhiên:

• Người giới thiệu là trangB với Chrome
• Người giới thiệu là EMPTY với FireFox & IE!

Hy vọng điều này có thể giúp