Blog

Mã trạng thái 203 Non-Authoritative Information là gì? Giải thích chi tiết

INEZA Felin-Michel

INEZA Felin-Michel

15 tháng 9 2025

Mã trạng thái 203 Non-Authoritative Information là gì? Giải thích chi tiết

Bạn đang duyệt web và một trang tải ngay lập tức. Điều bạn có thể không nhận ra là hình ảnh bạn đang thấy, biểu định kiểu (stylesheet) định dạng trang hoặc tập lệnh (script) làm cho trang tương tác rất có thể không đến trực tiếp từ máy chủ của trang web gốc. Nó đến từ một bên trung gian – một proxy bộ nhớ đệm (caching proxy) hoặc Mạng phân phối nội dung (CDN) như Cloudflare hay Akamai.

Cơ sở hạ tầng ẩn này là thứ giúp web hiện đại nhanh chóng và có khả năng mở rộng. Nhưng nó cũng tạo ra một lớp phức tạp: làm thế nào để hệ thống thông báo rằng một phản hồi đã được sửa đổi hoặc được phục vụ từ một nguồn khác với nguồn gốc?

Nếu bạn đã từng duyệt web hoặc làm việc với các API, bạn có thể đã gặp nhiều mã trạng thái HTTP khác nhau. Hầu hết mọi người đều quen thuộc với các mã phổ biến như 200 OK hoặc 404 Not Found, nhưng còn những mã ít phổ biến hơn như 203 Non-Authoritative Information thì sao? Trong bài đăng blog này, chúng ta sẽ khám phá ý nghĩa của mã trạng thái 203, khi nào nó xuất hiện và tại sao nó lại quan trọng, đặc biệt đối với các nhà phát triển và người dùng API muốn hiểu rõ hơn về các sắc thái của giao tiếp web.

Đây là nhiệm vụ đặc thù của một trong những mã trạng thái HTTP ít được biết đến và hiếm khi thấy nhất: 203 Non-Authoritative Information.

Mã trạng thái này là cách máy chủ (hoặc chính xác hơn là proxy) nói rằng: "Này, tôi đang cung cấp cho bạn thứ bạn yêu cầu, nhưng bạn nên biết rằng tôi không phải là nguồn gốc ban đầu và tôi có thể đã thực hiện một số thay đổi trên đường đi."

Nó tương đương với việc nhận được một bản ghi nhớ từ trợ lý của sếp bạn. Thông tin là hợp lệ và đến từ đúng nơi, nhưng nó đã được diễn giải hoặc tóm tắt, không phải là một trích dẫn trực tiếp, nguyên văn từ chính sếp.

Nếu bạn là nhà phát triển làm việc với proxy, CDN hoặc API gateway, việc hiểu mã này là chìa khóa để nắm vững HTTP chuyên sâu.

Và trước khi chúng ta đi sâu vào chi tiết, nếu bạn đang xây dựng hoặc thử nghiệm các API nằm sau các gateway và proxy, bạn cần một công cụ cung cấp khả năng hiển thị sâu sắc vào toàn bộ cuộc hội thoại HTTP. Tải Apidog miễn phí; đây là một nền tảng API tất cả trong một cho phép bạn kiểm tra mọi tiêu đề và mã trạng thái, giúp bạn gỡ lỗi các tương tác phức tạp liên quan đến các bên trung gian.

button

Bây giờ, hãy cùng phân tích mọi thứ bạn cần biết về 203 Non-Authoritative Information một cách đơn giản.

Các nhân vật trong một yêu cầu web

Để hiểu 203, chúng ta cần hiểu hành trình điển hình của một yêu cầu web, vốn hiếm khi là một cuộc trò chuyện hai chiều đơn giản.

  1. Client (Bạn): Trình duyệt web hoặc ứng dụng của bạn đang thực hiện một yêu cầu.
  2. Máy chủ gốc (Origin Server): Nguồn thông tin cuối cùng, máy chủ lưu trữ trang web hoặc API.
  3. Trung gian (The Middleman): Đây có thể là một số thứ:

Mã trạng thái 203 được tạo ra bởi bên trung gian này, chứ không phải máy chủ gốc.

HTTP 203 Non-Authoritative Information có nghĩa là gì?

Định nghĩa chính thức (từ RFC 7231) nêu rõ rằng phản hồi 203 có nghĩa là:

Yêu cầu thành công nhưng phần tải trọng đính kèm đã được một proxy biến đổi sửa đổi so với phản hồi 200 OK của máy chủ gốc.

Hãy cùng phân tích các cụm từ chính:

Về bản chất, bên trung gian đang minh bạch. Nó đang nói, "Tôi không phải là máy chủ gốc, và tôi đã làm gì đó với phản hồi này trước khi gửi nó cho bạn."

Nói một cách đơn giản, phản hồi 203 cho biết rằng máy chủ đã xử lý yêu cầu thành công, tương tự như trạng thái 200 OK. Tuy nhiên, thông tin trả về đến từ một bên thứ ba hoặc một nguồn khác mà máy chủ tin cậy nhưng không chính thức kiểm soát. Do đó, thông tin có thể đã được proxy hoặc gateway sửa đổi hoặc bổ sung trước khi gửi cho client.

Nói một cách đơn giản: Phản hồi tốt, nhưng dữ liệu có thể không chính xác như những gì máy chủ gốc, có thẩm quyền có – hãy nghĩ về nó như việc nhận được một phiên bản nội dung gốc đã được lọc hoặc nâng cao.

Tại sao mã trạng thái 203 lại tồn tại?

Bạn có thể tự hỏi, tại sao lại có mã trạng thái này? Tại sao không chỉ luôn gửi 200 OK?

Lý do nằm ở tính minh bạch và khả năng kiểm soát. Hãy tưởng tượng một máy chủ proxy bộ nhớ đệm hoặc một mạng phân phối nội dung (CDN). Các bên trung gian này thường phục vụ các bản sao nội dung web để giảm tải cho máy chủ chính và cải thiện tốc độ. Đôi khi, chúng sửa đổi hoặc thêm thông tin trước khi chuyển tiếp.

Lý do 203 tồn tại là để giúp phân biệt giữa các phản hồi gốc và phản hồi đã được sửa đổi. Đôi khi các proxy hoặc middleware thay đổi phản hồi, ví dụ:

Sử dụng 203 nói với client rằng, "Này, đây là dữ liệu bạn yêu cầu, nhưng hãy lưu ý rằng nó có thể đã được một bên trung gian thay đổi hoặc nâng cao."

Tính minh bạch này đặc biệt hữu ích trong việc gỡ lỗi, ghi nhật ký hoặc khi nguồn gốc dữ liệu nghiêm ngặt là quan trọng – ví dụ, trong các phản hồi API nơi nguồn dữ liệu ảnh hưởng đến độ tin cậy hoặc tuân thủ.

Các đặc điểm chính của 203

Đây là những gì làm cho 203 trở nên độc đáo:

Tại sao một proxy lại sửa đổi phản hồi? Các trường hợp sử dụng phổ biến

Một bên trung gian không thay đổi phản hồi mà không có lý do. Dưới đây là các kịch bản phổ biến nhất mà 203 có thể được sử dụng:

  1. Thêm hoặc sửa đổi tiêu đề: Đây là cách sử dụng phổ biến nhất. Một CDN có thể thêm tiêu đề Via để cho biết nó đã xử lý yêu cầu hoặc tiêu đề X-Cache để chỉ ra liệu đó là HIT hay MISS bộ nhớ đệm. Một API gateway có thể chèn tiêu đề RateLimit-Limit.
  2. Chuyển đổi nội dung: Một proxy có thể hạ cấp hình ảnh xuống chất lượng thấp hơn để tiết kiệm băng thông trên mạng di động. Nó có thể rút gọn (minify) các tệp JavaScript hoặc CSS để làm cho chúng nhỏ hơn và tải nhanh hơn.
  3. Chú thích: Một proxy quét bảo mật có thể thêm chú thích vào phần thân HTML cho biết các liên kết đã được kiểm tra an toàn.
  4. Bộ nhớ đệm: Mặc dù một phản hồi được lưu trong bộ nhớ đệm thường trả về 200 hoặc 304, một proxy có thể sử dụng 203 nếu nó áp dụng một số logic cho nội dung được lưu trong bộ nhớ đệm trước khi phục vụ nó.

Cơ chế: Cách tạo phản hồi 203

Hãy cùng xem xét một ví dụ giả định liên quan đến một API gateway.

  1. Yêu cầu từ Client: Một client gửi yêu cầu đến một API.
GET /api/users/me HTTP/1.1Host: api.example.comAuthorization: Bearer <token>

2.  Xử lý tại Gateway: Yêu cầu đến một API gateway trước tiên. Gateway:

3.  Phản hồi từ Origin: Dịch vụ backend xử lý yêu cầu và phản hồi.

HTTP/1.1 200 OKContent-Type: application/jsonServer: Origin-Server/1.0
{"id": 123, "username": "johndoe", "email": "john@example.com"}

4.  Chuyển đổi tại Gateway: Gateway nhận được phản hồi này. Trước khi gửi cho client, nó quyết định thêm một số thông tin hữu ích.

5.  Phản hồi 203 của Gateway gửi đến Client: Gateway xác định rằng nó đã sửa đổi phản hồi đủ để đảm bảo trạng thái 203. Nó gửi điều này đến client:

HTTP/1.1 203 Non-Authoritative InformationContent-Type: application/jsonServer: Origin-Server/1.0Via: 1.1 api-gatewayX-RateLimit-Limit: 1000
{"id": 123, "username": "johndoe", "email": "john@example.com"}

Lưu ý rằng phần thân vẫn giống nhau, nhưng các tiêu đề khác nhau và mã trạng thái đã thay đổi từ 200 sang 203.

Xử lý phản hồi 203 trong phát triển API

Nếu bạn đang xây dựng hoặc sử dụng API, việc hiểu và xử lý mã trạng thái 203 có thể giúp bạn xây dựng các hệ thống đáng tin cậy và minh bạch hơn.

Dưới đây là những gì bạn nên xem xét:

203 so với 200 OK: Một sự khác biệt quan trọng

Đây là sự so sánh quan trọng nhất. Tại sao lại sử dụng 203 thay vì chỉ chuyển tiếp 200 của nguồn gốc?

203 là một tín hiệu về tính minh bạch và một cảnh báo cho client rằng phản hồi không phải là một bản sao nguyên vẹn, trực tiếp từ nguồn.

Thực tế: Tại sao bạn hầu như không bao giờ thấy 203

Mặc dù được định nghĩa trong tiêu chuẩn HTTP, mã trạng thái 203 cực kỳ hiếm gặp trong thực tế. Đây là lý do:

  1. Thiếu sự chấp nhận rộng rãi: Nhiều nhà phát triển proxy và CDN đơn giản là không triển khai nó. Quan điểm phổ biến là việc thêm tiêu đề không phải là một sự biến đổi đủ đáng kể để cần thay đổi mã trạng thái.
  2. Nguy cơ làm hỏng Client: Một client được viết kém có thể xử lý 200 thành công nhưng lại gặp lỗi với 203, mặc dù cả hai đều là mã thành công. Để tránh rủi ro này, các bên trung gian hầu như luôn chỉ chuyển tiếp mã trạng thái của nguồn gốc.
  3. Tiêu đề được coi là "An toàn": Cách giải thích phổ biến giữa các nhà phát triển proxy là việc thêm các tiêu đề thông tin (như tiêu đề Via, X-Cache, Rate-Limit) không cấu thành một sự sửa đổi "tải trọng" hoặc "thông tin" mà cần đến 203. Họ xem "thông tin" là phần thân, chứ không phải các tiêu đề.
  4. Thường không cần thiết: Bên trung gian có thể đơn giản sử dụng các tiêu đề khác để truyền tải thông tin về chính nó. Bản thân tiêu đề Via đã đủ để cho client biết rằng một proxy đã tham gia, mà không cần thay đổi mã trạng thái.

Khi nào bạn thực sự có thể thấy 203?

Mặc dù hiếm, nhưng nó không tuyệt chủng. Bạn có thể gặp nó trong:

203 trong REST API so với GraphQL API

Kiểm tra và gỡ lỗi với Apidog

Làm việc với nhiều mã trạng thái HTTP khác nhau, đặc biệt là những mã không phổ biến như 203, đòi hỏi các công cụ thông minh. Dù bạn đang xây dựng một proxy có thể tạo ra 203 hay sử dụng một API làm điều đó, bạn cần một công cụ có thể nắm bắt và hiểu được những sắc thái này. Apidog là hoàn hảo cho việc này.

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

  1. Ghi lại toàn bộ phản hồi: Kiểm tra không chỉ mã trạng thái mà còn mọi tiêu đề, cho phép bạn phát hiện các sửa đổi có thể đã kích hoạt 203.
  2. So sánh yêu cầu: Dễ dàng phát lại một yêu cầu qua các đường dẫn khác nhau (ví dụ: trực tiếp đến nguồn gốc so với qua một gateway) và sử dụng các tính năng so sánh của Apidog để xem sự khác biệt trong các phản hồi.
  3. Kiểm tra khả năng phục hồi của Client: Nếu bạn đang xây dựng một client, bạn có thể sử dụng máy chủ giả lập của Apidog để mô phỏng phản hồi 203 và đảm bảo ứng dụng của bạn xử lý nó một cách chính xác mà không bị lỗi.
  4. Tài liệu hóa hành vi: Tài liệu hóa hành vi dự kiến của các API và proxy của bạn, bao gồm các mã trạng thái tiềm năng như 203, ngay trong không gian làm việc Apidog của bạn.
button

Mức độ kiểm tra sâu sắc này rất quan trọng để hiểu các tương tác phức tạp xảy ra giữa client và máy chủ gốc của bạn. Bằng cách tích hợp Apidog vào quy trình làm việc của bạn, bạn có thể tiết kiệm thời gian và giảm sự nhầm lẫn khi làm việc với các trạng thái HTTP tinh tế.

Apidog so với các công cụ API khác để kiểm tra 203

Thực hành tốt nhất: Nếu bạn đang triển khai một Proxy

Nếu bạn đang xây dựng một proxy biến đổi và muốn tuân thủ nghiêm ngặt đặc tả HTTP, hãy xem xét các hướng dẫn sau:

Những hiểu lầm phổ biến về mã trạng thái 203

Hãy cùng làm rõ một vài lầm tưởng:

Kết luận: Một mã của sự minh bạch

Mã trạng thái HTTP 203 Non-Authoritative Information, mặc dù phần lớn là một sự tò mò lịch sử trong web ngày nay, nhưng nó đại diện cho một nguyên tắc quan trọng: tính minh bạch trong giao tiếp.

Đó là một cơ chế để các bên trung gian thường vô hình của web trung thực về vai trò của họ. Họ không phải là nguồn gốc của sự thật, và nếu họ đã thay đổi điều gì đó, họ nên nói ra.

Với tư cách là nhà phát triển, việc hiểu 203 giúp bạn:

Điều này giúp client đưa ra các quyết định sáng suốt về độ tin cậy của dữ liệu và cải thiện việc gỡ lỗi trong các hệ sinh thái mạng phức tạp. Đối với hầu hết các nhà phát triển, bạn có thể sẽ không bao giờ cần chủ động sử dụng hoặc xử lý mã trạng thái này. Nhưng việc hiểu mục đích của nó mang lại cho bạn sự đánh giá sâu sắc hơn về sự phức tạp của HTTP và kiến trúc phân lớp của internet. Nó nhắc nhở chúng ta rằng một phản hồi không chỉ là một phần thân và một trạng thái; đó là một câu chuyện về hành trình mà một yêu cầu đã trải qua, và mã trạng thái 203 là một trong những cách để kể câu chuyện đó.

Đối với phần lớn công việc API của bạn, bạn sẽ làm việc với các mã trạng thái 200, 201, 400 và 500. Nếu bạn muốn khám phá các mã trạng thái như 203 hiệu quả hơn hoặc kiểm tra API của mình với những thông tin chi tiết, đừng quên tải Apidog miễn phí. Apidog đơn giản hóa việc kiểm thử và tài liệu API, hỗ trợ nhiều mã trạng thái HTTP để giúp trải nghiệm phát triển của bạn mượt mà hơn. Và để thiết kế, kiểm thử và tài liệu hóa các API đó, một công cụ như Apidog cung cấp nền tảng tất cả trong một hiện đại mà bạn cần để đảm bảo các API của bạn mạnh mẽ, đáng tin cậy và dễ sử dụng, bất kể có bao nhiêu bên trung gian tham gia vào chuỗi.

button

Thực hành thiết kế API trong Apidog

Khám phá cách dễ dàng hơn để xây dựng và sử dụng API

Đăng ký miễn phíTải xuống