Đoạn URL và chuyển hướng 302

Mọi người đều biết rằng đoạn URL (phần sau #) không được gửi đến máy chủ.

Tôi tự hỏi mặc dù các đoạn hoạt động như thế nào khi một máy chủ chuyển hướng (thông qua trạng thái HTTP 302 và Location:tiêu đề) có liên quan.

Câu hỏi của tôi thực sự là hai lần:

1. Nếu URL ban đầu có một đoạn ( /original.php#foo) và chuyển hướng được thực hiện /new.php, phần mảnh của URL gốc có bị mất không? Hay đôi khi nó được áp dụng cho URL mới?
   URL mới sẽ bao giờ /new.php#footrong trường hợp này?

2. Bất kể URL gốc là gì, nếu máy chủ chuyển hướng đến một URL mới với một đoạn ( /new.php#foo), đoạn đó có được "vinh danh" không? Hoặc máy chủ thực sự không có doanh nghiệp can thiệp vào đoạn nào cả - và do đó trình duyệt sẽ bỏ qua nó bằng cách đơn giản là đi đến /new.php??

Cập nhật 2014-Jun-27 :

RFC 7231, Giao thức truyền siêu văn bản (HTTP / 1.1): Ngữ nghĩa và nội dung , đã được xuất bản dưới dạng TIÊU CHUẨN ĐỀ XUẤT. Từ Changelog :

Cú pháp của trường tiêu đề Vị trí đã được thay đổi để cho phép tất cả các tham chiếu URI, bao gồm các tham chiếu và đoạn tương đối, cùng với một số giải thích về việc sử dụng các đoạn sẽ không phù hợp. (Mục 7.1.2)

Những điểm quan trọng từ Mục 7.1.2. Địa điểm :

Nếu giá trị Vị trí được cung cấp trong phản hồi 3xx (Chuyển hướng) không có thành phần phân đoạn, tác nhân người dùng PHẢI xử lý chuyển hướng như thể giá trị kế thừa thành phần phân đoạn của tham chiếu URI được sử dụng để tạo mục tiêu yêu cầu (nghĩa là chuyển hướng kế thừa đoạn tham chiếu ban đầu, nếu có).

Ví dụ: một yêu cầu GET được tạo cho tham chiếu URI " http://www.example.org/~tim " có thể dẫn đến phản hồi 303 (Xem Khác) có chứa trường tiêu đề:

Location: /People.html#tim

trong đó gợi ý rằng tác nhân người dùng chuyển hướng đến " http://www.example.org/P People.html # tim "

Tương tự, một yêu cầu GET được tạo cho tham chiếu URI " http://www.example.org/index.html#larry " có thể dẫn đến phản hồi 301 (Đã di chuyển vĩnh viễn) có chứa trường tiêu đề:

Location: http://www.example.net/index.html

trong đó gợi ý rằng tác nhân người dùng chuyển hướng đến " http://www.example.net/index.html#larry ", giữ nguyên định danh phân đoạn gốc.

Điều này sẽ trả lời rõ ràng câu hỏi của bạn.

Cập nhật KẾT THÚC

đây là một vấn đề mở (không được chỉ định) với đặc tả HTTP hiện tại . nó được giải quyết trong 2 vấn đề của nhóm làm việc http : IETF :

• # 6: Các mảnh vỡ được cho phép trong Vị trí
• # 43: Kết hợp / ưu tiên phân đoạn trong quá trình chuyển hướng

# 6 cho phép các đoạn trong Locationtiêu đề. # 43 nói điều này:

Tôi chỉ thử nghiệm điều này với các trình duyệt khác nhau.

• Firefox và Safari sử dụng đoạn trong tiêu đề vị trí.
• Opera sử dụng đoạn từ URI nguồn, khi có mặt, nếu không thì đoạn từ vị trí chuyển hướng
• IE (8) bỏ qua đoạn trong URI vị trí, do đó sẽ sử dụng đoạn từ URI nguồn, khi có mặt

Đề nghị:

"Lưu ý: hành vi khi số nhận dạng phân đoạn từ URI gốc và chuyển hướng cần được kết hợp là không xác định; Đại lý người dùng hiện tại thực sự khác nhau về phân đoạn được ưu tiên."

[...]

Dường như IE8 không sử dụng idenfitier đoạn từ Location(hành vi của tôi cưa có thể được giới hạn ở localhost).

Do đó, chúng tôi dường như có hành vi nhất quán đối với Safari / IE / Firefox / Chrome (vừa được thử nghiệm), trong đó đoạn từ tiêu đề Vị trí được sử dụng, bất kể URI ban đầu là gì.

Vì vậy, tôi thay đổi đề nghị của tôi để tài liệu đó như hành vi mong đợi.

điều này dẫn đến bằng chứng tương thích nhất với trình duyệt và tương lai (vì vấn đề này cuối cùng sẽ được chuẩn hóa) cho câu hỏi của bạn:

A: các đoạn từ URL gốc bị loại bỏ.

B: các mảnh từ Locationtiêu đề được vinh danh.

Safari 5 và IE9 trở xuống thả đoạn URI gốc nếu xảy ra chuyển hướng HTTP / 3xx. Nếu tiêu đề Vị trí trên phản hồi chỉ định một đoạn, nó sẽ được sử dụng.

IE10 +, Chrome 11+, Firefox 4+ và Opera đều sẽ "gắn lại" đoạn URI ban đầu sau khi chuyển hướng 3xx.

Trang thử nghiệm: http://www.webdbg.com/test/redir/fragment/ .

Xem thảo luận thêm về vấn đề này tại http://bloss.msdn.com/b/ieiternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx

Chỉ cần cho bạn biết, ở đây bạn có thể tìm thấy thông số kỹ thuật thích hợp. bởi w3c xác định cách tất cả nên cư xử: http://www.w3.org/TR/cuap#uri - khoản 4.1 - xem bên dưới:

Khi tài nguyên (URI1) đã di chuyển, chuyển hướng HTTP có thể chỉ ra vị trí mới của nó (URI2).

Nếu URI1 có số nhận dạng phân đoạn #frag, thì mục tiêu mới mà tác nhân người dùng sẽ cố gắng tiếp cận sẽ là URI2 # Frag. Nếu URI2 đã có mã định danh phân đoạn, thì #frag không được thêm vào và mục tiêu mới là URI2.

Sai: Hầu hết các tác nhân người dùng hiện tại thực hiện chuyển hướng HTTP nhưng không nối thêm mã định danh phân đoạn vào URI mới, điều này thường gây nhầm lẫn cho người dùng vì chúng kết thúc với tài nguyên sai.

Người giới thiệu:

Chuyển hướng HTTP được mô tả trong phần 10.3 của đặc tả HTTP / 1.1 [RFC2616]. Hành vi bắt buộc được mô tả chi tiết trong "Xử lý số nhận dạng phân đoạn trong các URL được chuyển hướng" [RURL]. Thuật ngữ "Bộ định vị tài nguyên thống nhất liên tục (PURL)" chỉ định một URL (trường hợp đặc biệt của URI) trỏ đến một URL khác thông qua chuyển hướng HTTP. Để biết thêm thông tin, hãy tham khảo "Bộ định vị tài nguyên thống nhất liên tục" [PURL]. Thí dụ:

Giả sử rằng người dùng yêu cầu tài nguyên tại http://www.w3.org/TR/WD-ruby/#changes và máy chủ chuyển hướng tác nhân người dùng đến http://www.w3.org/TR/ruby/ . Trước khi tìm nạp URI sau đó, trình duyệt sẽ nối thêm số nhận dạng phân đoạn #changes vào nó: http://www.w3.org/TR/ruby/#changes .

Đăng vấn đề tương tự với giải pháp mà tôi phải đối mặt.

Hy vọng nó sẽ giúp cho ai đó có yêu cầu tương tự preserving hash in IEđối với 302 chuyển hướng.