HTTP 301 so với 302 Redirects

Tính lâu dài mô tả mối quan hệ tài nguyên

HTTP 301 truyền đạt rằng tài nguyên đích có một URI vĩnh viễn mới, trong khi 302 truyền đạt một vị trí tạm thời. Các ngữ nghĩa chuyển hướng HTTP xác định sự khác biệt đó và vai trò của trường Location. Đích chuyển hướng có thể là một đường dẫn khác trên cùng nguồn hoặc một nguồn khác.

Đối với một bài viết cũ đã được chuyển vĩnh viễn, 301 thể hiện mối quan hệ được mong muốn. Đối với một quyết định định tuyến ngắn hạn, 302 có thể giữ URL gốc làm tham chiếu trong tương lai. Hãy chọn mã trạng thái dựa trên vòng đời thực tế được kỳ vọng thay vì dựa trên mong muốn làm trình duyệt rời khỏi trang.

Giữ ánh xạ cụ thể. Chuyển hướng mọi bài viết bị thiếu về trang chủ không giữ được ý nghĩa của từng tài nguyên. Một khách có thể đến trang chủ thành công nhưng lại thất bại trong việc lấy bài viết mà nó yêu cầu. Hãy xác thực tiêu đề đích và nội dung chính có liên quan như một phần của tiêu chí chấp nhận chuyển hướng.

Bảo toàn phương thức là một yêu cầu riêng

301 và 302 cho phép user agent đổi POST thành GET khi theo chuyển hướng. Hành vi lịch sử đó quan trọng với form và API vì yêu cầu được chuyển hướng có thể không còn đại diện cho thao tác ban đầu. Đừng chọn giữa chúng chỉ dựa trên tính lâu dài khi phương thức yêu cầu mang ý nghĩa nghiệp vụ.

307 là biến thể tạm thời bảo toàn phương thức và 308 là biến thể vĩnh viễn bảo toàn phương thức. Bảo toàn phương thức không loại bỏ nhu cầu kiểm tra đích, đặc biệt khi có thân yêu cầu hoặc thông tin xác thực. Một chuyển hướng sang nguồn khác tạo nên một ranh giới bảo mật và ứng dụng riêng biệt.

Với một yêu cầu gửi xuất dữ liệu giả định, hãy quyết định liệu khách nên lặp lại việc gửi tại một endpoint khác hay điều hướng đến trang kết quả sau thao tác. Đó là những luồng công việc khác nhau. 303 có thể thể hiện việc truy xuất một tài nguyên khác sau một thao tác. Hãy ghi lại phương thức mong muốn và tài nguyên kết quả thay vì coi mọi mã trạng thái chuyển hướng như các điều khiển điều hướng có thể hoán đổi cho nhau.

Chuyển hướng tạm thời vẫn có thể được lưu vào bộ nhớ đệm

Bộ nhớ đệm phụ thuộc vào ngữ nghĩa trạng thái, header phản hồi và các quy tắc áp dụng của bộ nhớ đệm. Đặc tả bộ nhớ đệm HTTP mô tả điều kiện độ tươi và lưu trữ. 301 đủ điều kiện cho bộ nhớ đệm suy đoán theo các quy tắc liên quan, trong khi 302 có thể được lưu vào bộ nhớ đệm khi các điều kiện rõ ràng cho phép.

Hãy thiết lập chính sách bộ nhớ đệm một cách có chủ đích. Một thử nghiệm định tuyến tạm thời với thời gian tươi quá dài có thể vẫn hiển thị sau khi quy tắc định tuyến thay đổi. Một lần di chuyển vĩnh viễn với hành vi bộ nhớ đệm không nhất quán cũng có thể tạo ra các quan sát khác nhau giữa các khách. Mã trạng thái và cấu hình bộ nhớ đệm nên kể một câu chuyện tương thích.

Hãy kiểm thử với cả trạng thái khách mới và trạng thái đã từng quan sát chuyển hướng. Ghi lại header phản hồi và chuỗi tại thời điểm kiểm tra. Nếu các khách khác nhau đi tới các đích khác nhau, hãy so sánh các chuyển hướng được lưu và hành vi trung gian trước khi cho rằng nguồn gốc đang phục vụ các ánh xạ khác nhau. Bộ nhớ đệm là một phần bằng chứng, không phải tiếng ồn nền.

Tín hiệu tìm kiếm phải khớp với ý định di chuyển

Công cụ tìm kiếm diễn giải chuyển hướng vĩnh viễn và tạm thời như những tín hiệu khác nhau về URL được ưu tiên. Phần hướng dẫn về chuyển hướng trong Google Search giải thích các loại chuyển hướng phía máy chủ và các tác động của chúng đến chuẩn hoá (canonicalization). Những tín hiệu này phải phù hợp với ánh xạ tài nguyên dự định.

Một lần di chuyển site vĩnh viễn cũng cần cập nhật các tham chiếu nội bộ và cung cấp một đích đến mạch lạc. Đừng dùng chuyển hướng làm nơi duy nhất mà cấu trúc mới tồn tại. Một đích chiến dịch tạm thời cần có điều kiện kết thúc rõ ràng để một quy tắc ngắn hạn không trở thành tuyến đường vĩnh viễn không được ghi chép.

Tránh đưa ra cam kết về thời điểm kết quả tìm kiếm sẽ thay đổi. Thu thập dữ liệu (crawl) và lập chỉ mục là các quá trình tách biệt, và một chuyển hướng hợp lệ không tạo ra việc cập nhật tức thì cho mọi bề mặt tìm kiếm. Hãy xác minh chuyển hướng về mặt kỹ thuật, rồi đánh giá các quan sát tìm kiếm dựa trên bằng chứng và thời điểm riêng của chúng. Giữ sự đúng đắn của giao thức tách biệt với giả định về kết quả xếp hạng hoặc lập chỉ mục.

Xác thực toàn bộ chuỗi và biểu diễn cuối cùng

Một lần kiểm tra chuyển hướng nên ghi lại URL gốc, từng bước nhảy, trạng thái, giá trị Location đã được phân giải và URL cuối cùng. Dừng vòng lặp và áp dụng giới hạn chiều dài chuỗi trong cấu hình client. Một phản hồi cuối cùng thành công là chưa đủ nếu phần thân là trang đăng nhập, trang chủ hoặc tài nguyên không liên quan.

Phân giải các đích tương đối dựa trên URL phản hồi đúng. Cố ý giữ lại các tham số truy vấn liên quan, và tránh vô tình sao chép các giá trị nhạy cảm sang nguồn gốc khác. Đừng giả định mọi thông tin xác thực đều nên đi theo chuyển hướng. Hãy tuân theo hành vi bảo mật được tài liệu hoá của client và cơ chế xác thực.

Bao gồm một trường hợp nhạy cảm với phương thức khi endpoint chấp nhận các phương thức ngoài GET. Kiểm tra xem endpoint nhận có thấy phương thức và thao tác như mong muốn không. Một chuyển hướng có thể trông có vẻ đúng trên thanh địa chỉ trình duyệt nhưng lại làm hỏng một lần gửi API. Ghi nhận cả ý nghĩa phần thân lẫn cơ chế định tuyến để bài kiểm tra phản ánh người dùng thực tế.

Giữ nguyên nguồn gốc URL trong tập dữ liệu tìm kiếm

Một tập dữ liệu tìm kiếm nên phân biệt URL được quan sát trong kết quả với đích đến được phân giải qua điều hướng về sau. Scrapeless Google Search API cung cấp dữ liệu tìm kiếm có cấu trúc, trong khi làm giàu ở bước sau có thể thêm một lần quan sát URL khác. Giữ lại trường gốc thay vì âm thầm ghi đè lên nó.

hợp đồng URL tìm kiếm nhận biết chuyển hướng minh hoạ lý do vì sao một lớp bọc chuyển hướng và đích nhà phát hành cần được xử lý tường minh. Lưu trữ thời điểm và kết quả phân giải khi những chi tiết đó ảnh hưởng đến cách diễn giải. Một lần phân giải thất bại không chứng minh rằng kết quả tìm kiếm gốc đã vắng mặt.

URL chuẩn (canonical) đòi hỏi một phân biệt khác. Canonical được khai báo của một trang là một khẳng định bởi chính trang đó, không chỉ đơn thuần là địa chỉ cuối cùng sau chuyển hướng. Hãy giữ lại nguồn và phương thức cho từng trường. Sử dụng bảng giá Scrapeless hiện tại cho việc lập kế hoạch thu thập và đánh giá việc làm giàu URL như một khối lượng công việc riêng với phạm vi và giới hạn riêng.

Chọn và triển khai chuyển hướng với kế hoạch thoát

Chọn 301 khi tài nguyên được chuyển vĩnh viễn và 302 khi đích thay thế là tạm thời, rồi kiểm tra riêng việc bảo toàn phương thức. Nếu thao tác phải giữ nguyên phương thức, hãy đánh giá hành vi 308 hoặc 307 tương ứng. Xem chính sách bộ nhớ đệm (cache) như một phần của cấu hình triển khai.

Tạo một bảng kiểm kê ánh xạ trước khi thay đổi một nhóm URL. Bao gồm các đích dự kiến, quyền sở hữu, cách xử lý truy vấn và một bước kiểm tra chấp nhận đối với nội dung cuối cùng. Đối với quy tắc tạm thời, hãy ghi lại điều kiện huỷ bỏ nó. Đối với quy tắc vĩnh viễn, hãy cập nhật các liên kết bạn kiểm soát để client không phụ thuộc vô thời hạn vào một bước nhảy có thể tránh được.

Quan sát chuỗi đã triển khai từ môi trường của người dùng. Một reverse proxy hoặc CDN có thể thêm các chuyển hướng không xuất hiện trong cấu hình ứng dụng. So sánh phản hồi đã triển khai với ánh xạ dự kiến, và lưu lại bằng chứng cho các đường dẫn tiêu biểu. Hồ sơ triển khai rõ ràng giúp việc giải thích sự sai khác về định tuyến hoặc bộ nhớ đệm sau này dễ dàng hơn.

Kết luận

Chuyển hướng HTTP 301 vs 302 nên tuân theo tính vĩnh viễn dự định của tài nguyên, với việc bảo toàn phương thức và chính sách bộ nhớ đệm được kiểm tra riêng. Xác thực mọi bước nhảy và nội dung cuối cùng. Trong các pipeline dữ liệu, hãy giữ lại URL đã quan sát và ghi lại các URL đã phân giải hoặc canonical với nguồn gốc riêng của chúng để các thay đổi định tuyến không xoá đi những gì nguồn thực tế đã hiển thị.

Tài liệu tham khảo

• Kết quả có cấu trúc Google Search API
• Scrapeless Google Search API
• Nguồn gốc URL chuyển hướng trong các pipeline tìm kiếm