Mã Trạng Thái 307 Temporary Redirect Là Gì? Chuyển Hướng Tạm Thời Chính Xác

Bạn đang hoàn tất một giao dịch mua hàng lớn trực tuyến. Bạn điền thông tin thẻ tín dụng của mình, nhấp vào nút "Thanh toán ngay", và trong một khoảnh khắc ngắn ngủi, trình duyệt của bạn gửi một yêu cầu POST với tất cả dữ liệu nhạy cảm của bạn. Đột nhiên, máy chủ cần chuyển hướng bạn đến trang xác thực 3D Secure. Điều gì xảy ra với yêu cầu POST ban đầu chứa thông tin thanh toán của bạn? Nó có bị mất không? Nó có được gửi không chính xác không?

Kịch bản quan trọng này là nơi sự khác biệt tinh tế giữa các mã chuyển hướng HTTP trở nên cực kỳ quan trọng. Đó là công việc cụ thể của một trong những mã trạng thái chính xác và có giá trị nhất: 307 Temporary Redirect.

Trong khi người anh em 302 Found của nó là một "chuyển hướng tạm thời" nổi tiếng, 307 là người anh em nghiêm ngặt và đáng tin cậy hơn. Nó được tạo ra để giải quyết một sự mơ hồ quan trọng trong đặc tả HTTP gốc, đảm bảo rằng các hoạt động nhạy cảm như thanh toán và gửi biểu mẫu không bị xử lý sai trong quá trình chuyển hướng.

Đó là sự khác biệt giữa một hướng dẫn mơ hồ như "Đi đến đó" và một lệnh chính xác như "Lấy mọi thứ bạn định đưa cho tôi và đưa cho người khác thay vì tôi."

Nếu bạn là nhà phát triển đang xây dựng các ứng dụng web mạnh mẽ, đặc biệt là với các API xử lý thanh toán, đăng nhập hoặc gửi dữ liệu, việc hiểu 307 là điều cần thiết.

Và trước khi chúng ta đi sâu vào chi tiết kỹ thuật, nếu bạn đang xây dựng hoặc thử nghiệm các API liên quan đến các luồng chuyển hướng phức tạp, bạn cần một công cụ có thể xử lý những sắc thái này. Tải xuống Apidog miễn phí; đây là một nền tảng API tất cả trong một cho phép bạn dễ dàng kiểm tra các loại chuyển hướng khác nhau, xác minh rằng các phương thức yêu cầu được giữ nguyên và đảm bảo các đường dẫn quan trọng của ứng dụng của bạn an toàn và đáng tin cậy.

button

Bây giờ, hãy cùng tìm hiểu mọi thứ về mã trạng thái 307 Temporary Redirect.

Vấn đề: Sự mơ hồ của chuyển hướng 302

Để hiểu 307, trước tiên chúng ta phải hiểu lỗi mà nó được thiết kế để khắc phục. Câu chuyện bắt đầu với chuyển hướng tạm thời ban đầu, 302 Found.

Đặc tả HTTP/1.0 cho 302 rất mơ hồ. Nó nói rằng máy khách nên thực hiện chuyển hướng, nhưng nó không nói rõ liệu yêu cầu được chuyển hướng có nên sử dụng cùng một phương thức HTTP (ví dụ: POST, PUT) như yêu cầu gốc hay không.

Điều này dẫn đến một vấn đề: vì lý do an toàn, hầu hết các nhà cung cấp trình duyệt đã triển khai 302 bằng cách thay đổi phương thức của yêu cầu được chuyển hướng thành GET. Điều này có ý nghĩa đối với hầu hết các hoạt động duyệt web cơ bản nhưng gây ra thảm họa cho các tương tác được lập trình hoặc dựa trên API.

Kịch bản thảm họa:

Máy khách POST dữ liệu biểu mẫu đến /submit-payment.
Máy chủ phản hồi với 302 Found và tiêu đề Location: /confirm.
Trình duyệt theo dõi chuyển hướng bằng cách gửi yêu cầu GET đến /confirm.
Dữ liệu POST nhạy cảm bị mất. Điểm cuối /confirm, mong đợi một GET, có thể hiển thị một trang nhưng không biết phải xác nhận khoản thanh toán nào.

Mã trạng thái 307 được giới thiệu trong HTTP/1.1 để loại bỏ sự mơ hồ nguy hiểm này một lần và mãi mãi.

Mã 307 Temporary Redirect trong HTTP thực sự có nghĩa là gì?

Mã trạng thái 307 Temporary Redirect là một hướng dẫn rõ ràng, không mơ hồ. Nó cho biết tài nguyên mục tiêu tạm thời nằm dưới một URI khác và tác nhân người dùng KHÔNG ĐƯỢC thay đổi phương thức yêu cầu được sử dụng trong yêu cầu gốc khi nó thực hiện yêu cầu được chuyển hướng.

Nếu yêu cầu gốc là POST, yêu cầu được chuyển hướng phải là POST. Nếu nó là PUT, nó phải vẫn là PUT. Phương thức và phần thân phải giống hệt nhau.

Một phản hồi 307 điển hình trông như thế này:

HTTP/1.1 307 Temporary RedirectLocation: <https://auth.example.com/3d-secureContent-Type:> text/htmlContent-Length: 125
<html><head><title>307 Temporary Redirect</title></head><body><center><h1>307 Temporary Redirect</h1></center></body></html>

Điểm mấu chốt, như với tất cả các chuyển hướng, là tiêu đề Location: <https://auth.example.com/3d-secure>. Điều kỳ diệu nằm ở sự đảm bảo ngữ nghĩa của chính mã trạng thái 307.

Tại sao chuyển hướng tồn tại trong HTTP?

Chuyển hướng tồn tại để giúp máy chủ và máy khách truyền đạt những thay đổi về tính khả dụng của tài nguyên mà không làm gián đoạn trải nghiệm người dùng.

Một số tình huống phổ biến bao gồm:

Di chuyển trang web → Chuyển từ http:// sang https://.
Sự cố tạm thời → Chuyển hướng lưu lượng truy cập trong khi máy chủ được bảo trì.
Phiên bản API → Gửi máy khách đến một điểm cuối tạm thời mới hơn.

Nếu không có chuyển hướng, người dùng sẽ phải nhìn chằm chằm vào các thông báo lỗi mỗi khi tài nguyên di chuyển.

307 so với 302: Sự khác biệt quan trọng

Đây là sự khác biệt quan trọng nhất. Sự khác biệt nằm ở việc bảo toàn phương thức.

Tính năng	`302 Found`	`307 Temporary Redirect`
Đặc tả gốc	Mơ hồ về việc thay đổi phương thức.	Cấm rõ ràng việc thay đổi phương thức.
Hành vi trình duyệt điển hình	Thay đổi POST thành GET. Đây là sự khác biệt quan trọng.	Bảo toàn phương thức gốc (POST vẫn là POST).
An toàn	Không an toàn. Không nên sử dụng sau một yêu cầu không bất biến (như POST).	An toàn. Được thiết kế đặc biệt cho các yêu cầu không bất biến.
Tương tự	"Thông tin bạn đã gửi đã được nhận. Bây giờ vui lòng truy cập trang mới này để xem kết quả." (Dữ liệu được chuyển giao).	"Vui lòng gửi lại chính xác gói thông tin đó đến địa chỉ mới này." (Dữ liệu được chuyển hướng).

Khi nào nên sử dụng cái nào?

Sử dụng 302 Found khi bạn muốn chuyển hướng sau một POST nhưng việc gửi dữ liệu thực tế đã hoàn tất và chuyển hướng chỉ để hiển thị trang kết quả. (Mặc dù 303 See Other thường còn tốt hơn cho việc này).
Sử dụng 307 Temporary Redirect khi yêu cầu gốc (và phương thức/phần thân của nó) phải được gửi lại đến một URI khác để hoàn thành hành động. Điều này phổ biến trong các luồng xác thực, cổng thanh toán và chuỗi API.

Cách 307 Temporary Redirect hoạt động

Đây là một luồng đơn giản hóa:

1. Máy khách yêu cầu một tài nguyên:

POST /checkout HTTP/1.1
Host: shop.example.com

2. Máy chủ phản hồi với 307 Temporary Redirect:

HTTP/1.1 307 Temporary Redirect
Location: <https://secure.example.com/checkout>

3. Máy khách lặp lại yêu cầu POST tại vị trí mới:

POST /checkout HTTP/1.1
Host: secure.example.com

Điểm mấu chốt: Phương thức và phần thân yêu cầu được bảo toàn.

Một ví dụ thực tế: Luồng thanh toán

Hãy cùng xem xét kịch bản thanh toán để thấy 307 hoạt động.

1. Yêu cầu POST gốc: Người dùng gửi biểu mẫu thanh toán. Trình duyệt gửi:

POST /checkout/payment HTTP/1.1Host: shop.example.comContent-Type: application/x-www-form-urlencoded

card_number=4111...&expiry=12/25&cvc=123

2. Phản hồi 307 của máy chủ: Máy chủ của cửa hàng cần chuyển giao cho hệ thống 3D Secure của ngân hàng. Nó phản hồi:

HTTP/1.1 307 Temporary RedirectLocation: <https://api.bank.com/3d-secure/authenticate>

3. Yêu cầu POST được bảo toàn: Trình duyệt nhận phản hồi 307. Vì đặc tả không mơ hồ, nó biết rằng nó phải gửi lại chính xác yêu cầu POST đó với chính xác phần thân đó đến vị trí mới.

POST /3d-secure/authenticate HTTP/1.1Host: api.bank.comContent-Type: application/x-www-form-urlencoded

card_number=4111...&expiry=12/25&cvc=123

4. Kết quả cuối cùng: API của ngân hàng nhận trực tiếp thông tin chi tiết thanh toán, thực hiện xác thực, sau đó phản hồi cho máy khách bằng các bước tiếp theo (có thể là chuyển hướng 303 hoặc 302 trở lại trang xác nhận của cửa hàng).

Luồng này đảm bảo không có dữ liệu nhạy cảm nào bị mất giữa cửa hàng và ngân hàng.

Khi nào bạn nên sử dụng 307 so với 301 hoặc 302?

301 Moved Permanently → Khi vị trí tài nguyên sẽ không bao giờ thay đổi nữa.
302 Found → Khi tài nguyên tạm thời ở nơi khác, nhưng việc bảo toàn phương thức không quan trọng.
307 Temporary Redirect → Khi tài nguyên tạm thời ở nơi khác và bạn phải bảo toàn phương thức HTTP.

Quy tắc chung tốt nhất:

Sử dụng 301 cho các thay đổi vĩnh viễn.
Sử dụng 307 cho các di chuyển tạm thời liên quan đến các hoạt động nhạy cảm (như yêu cầu POST).

Lợi ích của việc sử dụng 307 Temporary Redirect

Dễ dự đoán → Phương thức yêu cầu luôn được bảo toàn.
Bảo mật → Ngăn chặn việc hạ cấp phương thức ngẫu nhiên (ví dụ: POST biến thành GET).
Rõ ràng cho nhà phát triển → Máy khách biết chính xác hành vi mong đợi.

Nhược điểm và những hiểu lầm phổ biến

Một số máy khách cũ hơn có thể không xử lý 307 đúng cách.
Các nhà phát triển đôi khi nhầm lẫn 307 với 302, dẫn đến hành vi không mong muốn.
Các chuyên gia SEO đôi khi hiểu sai 307 tương đương với 301 – điều đó không đúng.

307 và phát triển API

Trong thế giới API, 307 đóng một vai trò quan trọng:

Đảm bảo các yêu cầu không bất biến (như POST) vẫn nhất quán.
Giúp các cổng API định tuyến lưu lượng truy cập an toàn trong các thay đổi tạm thời.
Cung cấp một cách an toàn để xử lý thời gian bảo trì.

Nếu không có 307, các nhà phát triển có nguy cơ máy khách vô tình sửa đổi loại yêu cầu.

Kiểm tra chuyển hướng 307 với Apidog

Kiểm tra hành vi này là rất quan trọng. Nếu bạn đang xây dựng hoặc thử nghiệm API, bạn có thể muốn xem máy khách của mình xử lý phản hồi 307 như thế nào. Bạn phải đảm bảo rằng máy khách của mình xử lý đúng phản hồi 307 bằng cách bảo toàn phương thức và phần thân. Apidog là công cụ hoàn hảo cho việc này.

Với Apidog, bạn có thể:

Tạo yêu cầu POST: Dễ dàng thiết lập một yêu cầu POST với phần thân JSON hoặc form-data đến điểm cuối của bạn.
Giả lập phản hồi 307: Cấu hình máy chủ giả lập của bạn trong Apidog để trả về 307 Temporary Redirect với tiêu đề Location.
Quan sát chuyển hướng tự động: Apidog sẽ tự động theo dõi chuyển hướng. Bài kiểm tra chính là kiểm tra nhật ký yêu cầu cho yêu cầu thứ hai. Nó có bảo toàn phương thức POST không? Nó có gửi chính xác phần thân đó không?
So sánh với 302: Chạy cùng một bài kiểm tra nhưng yêu cầu giả lập của bạn trả về 302 thay vì. Quan sát cách Apidog (hoạt động như một trình duyệt tiêu chuẩn) thay đổi phương thức thành GET và bỏ qua phần thân. Minh họa trực quan này cho thấy rõ sự khác biệt.
Kiểm tra máy khách API: Nếu bạn đang xây dựng một máy khách API được lập trình (ví dụ: trong Node.js, Python), bạn có thể sử dụng Apidog để giả lập máy chủ và đảm bảo mã máy khách của bạn xử lý đúng phản hồi 307 bằng cách bảo toàn phương thức.

button

Mức độ kiểm tra này đảm bảo rằng các hoạt động quan trọng như thanh toán và đăng nhập sẽ không bị lỗi trong sản xuất. Tải xuống Apidog miễn phí và thử giả lập phản hồi 307 ngay hôm nay. Đó là một cách tuyệt vời để kiểm tra các ứng dụng của bạn trong điều kiện chuyển hướng thực tế.

Ý nghĩa SEO của 307 Temporary Redirect

Từ góc độ SEO:

307 cho công cụ tìm kiếm biết rằng chuyển hướng là tạm thời.
Không giống như 301, các công cụ tìm kiếm sẽ không chuyển giá trị liên kết (PageRank) sang URL mới.
Điều này hoàn hảo cho kiểm thử A/B, khuyến mãi hoặc các chiến dịch ngắn hạn.

Nếu bạn sử dụng 307 thay cho 301, bạn có nguy cơ mất các lợi ích SEO dài hạn.

307 so với 308 Permanent Redirect

Giống như 307 là đối tác nghiêm ngặt của 302, nó có một người anh em cho các di chuyển vĩnh viễn: 308 Permanent Redirect.

307 Temporary Redirect: "Tạm thời gửi lại cùng một yêu cầu đến URL khác này."
308 Permanent Redirect: "Vĩnh viễn gửi lại cùng một yêu cầu đến URL khác này. Cập nhật hồ sơ của bạn."

Sử dụng 307 cho bảo trì tạm thời, kiểm thử A/B hoặc các kịch bản dự phòng. Sử dụng 308 khi bạn đang thay đổi vĩnh viễn URL của một điểm cuối mong đợi các yêu cầu không phải GET.

Các cân nhắc về bảo mật với 307

Về mặt bảo mật, 307 thường an toàn hơn 302 vì nó tránh thao tác yêu cầu. Tuy nhiên, hãy nhớ:

Các chuyển hướng độc hại vẫn có thể dẫn người dùng đến các trang web lừa đảo.
Luôn sử dụng HTTPS trong tiêu đề Location để ngăn chặn các cuộc tấn công hạ cấp.

Triển khai và các phương pháp hay nhất

Đối với nhà phát triển máy chủ: Khi bạn cần tạm thời chuyển hướng một yêu cầu không bất biến (POST, PUT, DELETE), hãy sử dụng 307. Đó là lựa chọn an toàn nhất và chính xác nhất về mặt ngữ nghĩa.
Đối với nhà phát triển máy khách: Đảm bảo thư viện máy khách HTTP của bạn (ví dụ: Axios, Requests) xử lý đúng phản hồi 307 bằng cách gửi lại yêu cầu gốc đến vị trí mới. Hầu hết các thư viện hiện đại đều làm điều này đúng cách.
Luôn ưu tiên độ chính xác: Mặc định sử dụng 307 thay cho 302 khi bạn chắc chắn rằng phương thức phải được bảo toàn. Nó loại bỏ sự mơ hồ.

Các lựa chọn thay thế cho 307 Temporary Redirect

Tùy thuộc vào trường hợp sử dụng của bạn:

Sử dụng 308 Permanent Redirect nếu việc di chuyển là vĩnh viễn và bạn cần bảo toàn phương thức.
Sử dụng 302 Found nếu phương thức không quan trọng và khả năng tương thích ngược quan trọng hơn.
Sử dụng 301 Moved Permanently cho các vị trí di chuyển vĩnh viễn mà SEO là ưu tiên.

Kết luận: Sự đảm bảo an toàn

Mã trạng thái HTTP 307 Temporary Redirect là minh chứng cho sự phát triển của web hướng tới độ chính xác và an toàn cao hơn. Nó đã giải quyết một sự mơ hồ quan trọng trong giao thức có thể dẫn đến mất dữ liệu và các lỗ hổng bảo mật.

Mã trạng thái 307 Temporary Redirect không chỉ là một con số khác trong đặc tả HTTP. Nó giải quyết các vấn đề trong thế giới thực bằng cách đảm bảo rằng các phương thức và phần thân yêu cầu vẫn nguyên vẹn trong quá trình chuyển hướng.

Trong khi 302 và 303 có vị trí của chúng, 307 cung cấp một sự đảm bảo quan trọng: rằng một yêu cầu sẽ được gửi chính xác như dự định, ngay cả khi đích đến của nó thay đổi tạm thời. Điều này làm cho nó không thể thiếu để xây dựng các ứng dụng web đáng tin cậy, an toàn xử lý các hoạt động nhạy cảm.

Hiểu được sự khác biệt tinh tế giữa các mã chuyển hướng này là dấu hiệu của một nhà phát triển cấp cao. Và khi đến lúc kiểm tra và xác thực rằng các ứng dụng của bạn xử lý các chuyển hướng này một cách chính xác, một công cụ mạnh mẽ như Apidog cung cấp khả năng hiển thị và kiểm soát cần thiết để đảm bảo các chuyển hướng của bạn không chỉ hoạt động, mà còn hoạt động chính xác.

button