Trong kho tàng mã trạng thái HTTP phong phú, một số mã nổi bật hơn những mã khác, trong khi một số khác lại âm thầm đóng vai trò quan trọng trong việc đảm bảo giao tiếp client-server diễn ra suôn sẻ. Mã trạng thái 406 Not Acceptable là một trong những "người hùng thầm lặng" như vậy. Nó có thể không xuất hiện thường xuyên như 404 hoặc 500 phổ biến, nhưng việc hiểu rõ mục đích của nó có thể cải thiện đáng kể sự hiểu biết của bạn về đàm phán nội dung và nâng cao tính linh hoạt của các ứng dụng web và API của bạn.
Mã trạng thái 406 Not Acceptable có thể giống như một thông báo khó hiểu từ máy chủ của bạn. Nhưng một khi bạn hiểu ý nghĩa của nó, nó sẽ trở thành một tín hiệu mạnh mẽ giúp bạn thiết kế các API sạch hơn, dễ dự đoán hơn và thân thiện với người dùng hơn.
Mã trạng thái này thể hiện sự cố giao tiếp trong quá trình đàm phán nội dung phức tạp, nơi client và server thống nhất về định dạng tốt nhất để trao đổi dữ liệu.
Trong bài đăng trên blog này, chúng ta sẽ đi sâu vào ý nghĩa của HTTP 406 Not Acceptable, lý do nó xảy ra, cách đàm phán nội dung ảnh hưởng đến nó và cách bạn, với tư cách là nhà phát triển hoặc người tiêu dùng API, có thể xử lý nó một cách hiệu quả. Gỡ lỗi các lỗi lạ như 406 Not Acceptable có thể tốn thời gian nếu không có công cụ phù hợp. Đó là lý do tại sao tôi khuyên dùng Apidog. Đây là một nền tảng API tất cả trong một miễn phí cho phép bạn thiết kế, mô phỏng, kiểm thử, gỡ lỗi và tài liệu hóa API một cách dễ dàng để bạn biết chính xác lý do mình nhận được lỗi 406 và cách khắc phục nhanh chóng.
tải xuống
Bây giờ, hãy cùng khám phá thế giới đàm phán nội dung và mã trạng thái HTTP 406 Not Acceptable.
Vấn đề: Mọi người đều muốn dữ liệu theo cách riêng của họ
Trong những ngày đầu của web, các máy chủ thường cung cấp một định dạng cho tài nguyên của họ, thường là HTML. Nhưng khi web phát triển, các client khác nhau xuất hiện với các nhu cầu khác nhau:
- Trình duyệt web muốn HTML
- Ứng dụng di động muốn JSON
- Các dịch vụ khác có thể muốn XML
- Một số client có thể cần xuất PDF hoặc CSV
Mã trạng thái 406 tồn tại vì đôi khi một client yêu cầu một định dạng mà máy chủ đơn giản là không thể cung cấp cho tài nguyên cụ thể đó.
HTTP 406 Not Acceptable thực sự có nghĩa là gì?
Mã trạng thái 406 Not Acceptable cho biết rằng máy chủ không thể tạo ra một phản hồi phù hợp với danh sách các giá trị chấp nhận được được định nghĩa trong các tiêu đề đàm phán nội dung chủ động của yêu cầu, và rằng máy chủ không sẵn lòng cung cấp một biểu diễn mặc định.
Nói một cách đơn giản hơn: "Bạn đã nói cho tôi biết chính xác những định dạng bạn sẽ chấp nhận, và tôi không thể cung cấp tài nguyên đó dưới bất kỳ định dạng nào trong số đó."
Một phản hồi 406 đúng cách nên bao gồm thông tin về những định dạng mà máy chủ có thể cung cấp cho tài nguyên được yêu cầu. Điều này thường được thực hiện bằng các tiêu đề hoặc trong phần thân phản hồi.
Đây là những gì một phản hồi 406 có thể trông như thế này:
HTTP/1.1 406 Not AcceptableContent-Type: text/htmlVary: Accept
<html><head><title>406 Not Acceptable</title></head><body><h1>Not Acceptable</h1><p>This resource is available in the following formats:</p><ul><li>application/json</li><li>application/xml</li></ul></body></html>
Đối với API, việc trả về một phản hồi có cấu trúc sẽ hữu ích hơn:
HTTP/1.1 406 Not AcceptableContent-Type: application/jsonVary: Accept
{
"error": "not_acceptable",
"message": "The requested resource is not available in the requested format.",
"available_formats": [
"application/json",
"application/xml"
]
}
Vấn đề không phải là yêu cầu có hợp lệ hay không. Vấn đề là loại phản hồi có được chấp nhận hay không.
Sự kỳ diệu của Đàm phán nội dung: Cách hoạt động của tiêu đề Accept
Để hiểu 406, chúng ta cần hiểu cách client nói với server những định dạng mà chúng ưu tiên. Điều này xảy ra thông qua tiêu đề Accept.
Tiêu đề Accept trong thực tế
Khi một client thực hiện một yêu cầu, nó có thể chỉ định các loại nội dung mà nó có thể xử lý và những loại nào nó ưu tiên:
Một ví dụ đơn giản:
GET /api/users/123 HTTP/1.1Accept: application/json
Điều này có nghĩa: "Tôi muốn dữ liệu người dùng, và tôi chỉ hiểu JSON."
Một ví dụ phức tạp hơn:
GET /api/users/123 HTTP/1.1Accept: application/json, text/html;q=0.9, application/xml;q=0.8
Điều này có nghĩa: "Tôi ưu tiên JSON, nhưng tôi cũng có thể xử lý HTML (với ưu tiên 90%) và XML (với ưu tiên 80%)."
Tham số q (giá trị chất lượng) nằm trong khoảng từ 0 đến 1, với 1 là ưu tiên cao nhất.
Khi đàm phán thất bại
Lỗi 406 xảy ra khi máy chủ xem tiêu đề Accept và nhận ra:
- Nó có tài nguyên mà client muốn
- Nó không thể cung cấp tài nguyên đó dưới bất kỳ định dạng nào mà client đã chỉ định
- Nó không sẵn lòng gửi một định dạng mặc định (như gửi JSON cho một client chỉ chấp nhận XML)
406 Not Acceptable phù hợp với đàm phán nội dung như thế nào?
Khi một client gửi yêu cầu HTTP bao gồm các tiêu đề Accept chỉ định các loại phương tiện chấp nhận được (ví dụ: chỉ yêu cầu phản hồi JSON), máy chủ sẽ cố gắng phân phối nội dung tương ứng.
Nếu máy chủ không thể cung cấp bất kỳ nội dung chấp nhận được nào phù hợp với tiêu chí, nó sẽ phản hồi bằng:
textHTTP/1.1 406 Not Acceptable Content-Type: text/html
Tại thời điểm này, điều đó có nghĩa là máy chủ từ chối yêu cầu vì không có biểu diễn nội dung khả dụng nào khớp với sở thích của client.
Tại sao máy chủ trả về 406 thay vì 200 OK
Bạn có thể nghĩ: tại sao không chỉ trả về một cái gì đó, ngay cả khi nó không phải là định dạng ưu tiên?
Đây là lý do tại sao máy chủ trả về 406:
- Để thực thi các quy tắc đàm phán nội dung nghiêm ngặt.
- Để ngăn chặn việc gửi dữ liệu ở định dạng mà client đã nói rõ ràng rằng nó không thể chấp nhận.
- Để giúp các nhà phát triển gỡ lỗi dễ dàng hơn bằng cách báo hiệu các tiêu đề
Acceptkhông khớp.
Các nguyên nhân phổ biến của phản hồi 406
Dưới đây là một số lý do điển hình bạn sẽ thấy 406 Not Acceptable:
- Tiêu đề
Acceptkhông khớp → Client yêu cầuapplication/xmlnhưng máy chủ chỉ hỗ trợapplication/json. - Client API lỗi thời → Sử dụng các SDK cũ hơn mong đợi các định dạng phản hồi khác nhau.
- Cấu hình máy chủ không đúng → Đàm phán nội dung không được thiết lập đúng cách.
- Những điểm đặc biệt của framework → Một số framework (như Django hoặc Rails) thực thi xử lý
Acceptnghiêm ngặt. - Xử lý lỗi tùy chỉnh bị sai → Các bộ lọc quá nghiêm ngặt đối với các định dạng phản hồi.
Các tình huống thực tế gây ra lỗi 406
1. Xung đột phiên bản API
Hãy tưởng tượng một API chỉ phục vụ JSON trong phiên bản v2 của nó, nhưng một client vẫn mong đợi XML từ thời v1:
GET /v2/products/456 HTTP/1.1Accept: application/xmlHTTP/1.1 406 Not AcceptableContent-Type: application/json
{
"error": "This API version only supports JSON",
"available_formats": ["application/json"]
}
2. Cấu hình client quá hạn chế
Một ứng dụng di động có thể được mã hóa cứng để chỉ chấp nhận JSON, nhưng gặp một máy chủ chỉ phục vụ một số tài nguyên nhất định dưới dạng XML:
GET /reports/quarterly-sales HTTP/1.1Accept: application/jsonHTTP/1.1 406 Not Acceptable
(Báo cáo có thể chỉ có sẵn dưới dạng CSV hoặc PDF)
3. Thiếu cơ chế dự phòng mặc định
Một số máy chủ được cấu hình để nghiêm ngặt về đàm phán nội dung và từ chối đoán định dạng nào sẽ trả về khi đàm phán thất bại.
Máy chủ thường xử lý 406 như thế nào?
Điều thú vị là, một số máy chủ bỏ qua đàm phán nội dung nghiêm ngặt và quay trở lại phản hồi mặc định thay vì phản hồi bằng 406.
Tuy nhiên, các API RESTful hoặc dịch vụ nhấn mạnh giao tiếp chính xác có thể trả về 406 khi các yêu cầu của client không thể được đáp ứng.
406 Not Acceptable so với các mã trạng thái liên quan
Để làm rõ vai trò của 406, hãy xem xét các trạng thái HTTP liên quan:
| Mã trạng thái | Ý nghĩa | Khi nào sử dụng |
|---|---|---|
| 400 Bad Request | Cú pháp không đúng hoặc yêu cầu không hợp lệ | Yêu cầu không thể hiểu được |
| 406 Not Acceptable | Yêu cầu hợp lệ nhưng máy chủ không thể đáp ứng tiêu đề chấp nhận | Lỗi đàm phán nội dung |
| 415 Unsupported Media Type | Máy chủ không thể xử lý loại nội dung được client gửi | Kiểu phương tiện phần thân yêu cầu không hợp lệ |
| Sự khác biệt giữa 406 và 415 | 406 liên quan đến loại phản hồi, 415 liên quan đến loại phần thân yêu cầu | — |
Client nên xử lý phản hồi 406 như thế nào?
Client nhận 406 nên:
- Kiểm tra các tiêu đề đàm phán nội dung mà chúng đã gửi.
- Sửa đổi tiêu đề
Acceptđể bao gồm các loại phương tiện rộng hơn. - Thực hiện các cơ chế dự phòng để yêu cầu các định dạng mặc định (ví dụ:
/*). - Tôn trọng khả năng của máy chủ và giới hạn yêu cầu cho phù hợp.
- Cung cấp thông báo thân thiện với người dùng nếu các loại nội dung cụ thể không thể được phục vụ.
Các nhà phát triển có thể làm gì để tránh hoặc xử lý 406?
- Cung cấp nhiều biểu diễn nội dung (JSON, XML, HTML) nếu có thể.
- Triển khai logic đàm phán phía máy chủ để dự phòng một cách duyên dáng thay vì từ chối.
- Tài liệu hóa rõ ràng các loại phương tiện được hỗ trợ cho người tiêu dùng API.
- Ghi lại các phản hồi 406 để xác định sự không tương thích hoặc sự cố của client.
- Sử dụng các thư viện hoặc framework có hỗ trợ đàm phán nội dung tích hợp.
Trang và thông báo lỗi 406 tùy chỉnh
Đối với các trang web và API, việc phục vụ các phản hồi lỗi 406 có ý nghĩa và hữu ích sẽ cải thiện trải nghiệm của nhà phát triển và người dùng:
- Bao gồm các gợi ý về các loại nội dung được hỗ trợ.
- Cung cấp các liên kết hoặc ví dụ để sử dụng đúng cách.
- Sử dụng ngôn ngữ rõ ràng trong các thông báo lỗi.
- Tùy chỉnh các trang lỗi phù hợp với thương hiệu của trang web.
Kiểm thử đàm phán nội dung với Apidog

Kiểm thử cách API của bạn xử lý các tiêu đề Accept khác nhau là rất quan trọng để xây dựng các ứng dụng mạnh mẽ. Apidog giúp quá trình này trở nên đơn giản và hiệu quả.
Với Apidog, bạn có thể:
- Dễ dàng sửa đổi tiêu đề: Nhanh chóng thêm và sửa đổi tiêu đề
Acceptđể kiểm tra cách máy chủ của bạn phản hồi các yêu cầu loại nội dung khác nhau. - Kiểm tra nhiều định dạng: Tạo một bộ sưu tập các bài kiểm tra cho cùng một điểm cuối với các tiêu đề
Acceptkhác nhau (JSON, XML, HTML) để đảm bảo phạm vi bao phủ toàn diện. - Xác thực phản hồi 406: Cố ý gửi các tiêu đề
Accepthạn chế để xác minh rằng máy chủ của bạn trả về các phản hồi406phù hợp với thông tin lỗi hữu ích. - Tự động hóa kiểm thử đàm phán nội dung: Tạo các bộ kiểm thử tự động xác minh API của bạn xử lý chính xác các yêu cầu loại nội dung khác nhau và trả về các mã trạng thái thích hợp.
- Gỡ lỗi các tình huống phức tạp: Sử dụng nhật ký chi tiết của Apidog để hiểu chính xác lý do lỗi
406xảy ra và máy chủ thực sự hỗ trợ những định dạng nào.
tải xuống
Cách tiếp cận có hệ thống này đảm bảo API của bạn có thể xử lý một cách duyên dáng các client với các yêu cầu định dạng khác nhau. Tóm lại: thay vì mò mẫm trong bóng tối, bạn biết chính xác những gì được chấp nhận. Tải xuống Apidog miễn phí và tăng năng suất của bạn trong việc khắc phục sự cố đàm phán nội dung và các tình huống 406.
Các phương pháp hay nhất để xử lý lỗi 406
Đối với nhà phát triển máy chủ:
- Cung cấp thông tin lỗi hữu ích: Khi trả về
406, luôn bao gồm thông tin về các định dạng bạn có hỗ trợ. Điều này giúp các nhà phát triển client sửa lỗi yêu cầu của họ. - Sử dụng tiêu đề Vary: Bao gồm tiêu đề
Vary: Accepttrong các phản hồi của bạn để cho biết rằng nội dung phản hồi thay đổi dựa trên giá trị tiêu đề Accept. Điều này giúp các hệ thống bộ nhớ đệm hoạt động chính xác. - Cân nhắc hành vi mặc định: Mặc dù đặc tả HTTP cho phép máy chủ trả về một biểu diễn mặc định, nhiều API hiện đại chọn nghiêm ngặt và trả về
406để buộc client phải rõ ràng về các yêu cầu của họ. - Tài liệu hóa các định dạng được hỗ trợ: Tài liệu hóa rõ ràng các loại nội dung mà API của bạn hỗ trợ cho từng điểm cuối.
Đối với nhà phát triển client:
- Linh hoạt trong các tiêu đề Accept: Trừ khi bạn có lý do cụ thể, hãy bao gồm nhiều định dạng trong tiêu đề Accept của bạn với các giá trị chất lượng phù hợp.
- Xử lý 406 một cách duyên dáng: Khi bạn nhận được
406, hãy kiểm tra phản hồi để biết các định dạng có sẵn và điều chỉnh yêu cầu của bạn hoặc hiển thị thông báo lỗi hữu ích cho người dùng. - Có logic dự phòng: Cân nhắc có logic dự phòng có thể xử lý các định dạng khác nhau nếu định dạng ưu tiên chính của bạn không có sẵn.
Người hùng thầm lặng của đàm phán nội dung
Tiêu đề Vary rất quan trọng đối với hành vi bộ nhớ đệm thích hợp khi có đàm phán nội dung. Khi một máy chủ bao gồm Vary: Accept trong phản hồi của nó, nó cho bộ nhớ đệm biết rằng nội dung phản hồi phụ thuộc vào giá trị tiêu đề Accept.
Điều này ngăn bộ nhớ đệm phục vụ sai phản hồi JSON cho một client đã yêu cầu XML, hoặc ngược lại.
Tác động của phản hồi 406 đến SEO
Nhìn chung, 406 không ảnh hưởng đáng kể đến SEO vì các công cụ tìm kiếm thường xử lý đàm phán nội dung một cách mạnh mẽ và ưu tiên các phản hồi hợp lệ. Tuy nhiên, các API hoặc trang web được cấu hình sai thường xuyên trả về 406 có thể gây khó chịu cho các trình thu thập thông tin hoặc người dùng.
Thiết kế API hiện đại và 406
Trong thiết kế API RESTful hiện đại, việc sử dụng 406 đã phát triển:
- Nhiều API chỉ sử dụng JSON và không bận tâm đến đàm phán nội dung, khiến
406hiếm khi xảy ra. - Phiên bản hóa thông qua URL (ví dụ:
/v1/,/v2/) đã trở nên phổ biến hơn so với đàm phán nội dung cho các thay đổi định dạng. - API siêu phương tiện (HATEOAS) thường sử dụng đàm phán nội dung để phục vụ các biểu diễn khác nhau của cùng một tài nguyên.
Tuy nhiên, 406 vẫn phù hợp cho:
- Các API phục vụ nhiều định dạng dữ liệu
- Các hệ thống quản lý nội dung có thể xuất HTML, JSON và XML
- Các dịch vụ cung cấp xuất dữ liệu ở nhiều định dạng khác nhau
Khắc phục sự cố lỗi 406
- Kiểm tra các tiêu đề yêu cầu của client để tìm các giá trị
Accepthạn chế. - Xem xét các định dạng được máy chủ hỗ trợ và logic đàm phán.
- Sử dụng các công cụ như Apidog để thử nghiệm các kết hợp tiêu đề khác nhau.
- Điều chỉnh cấu hình client hoặc máy chủ để mở rộng các tùy chọn nội dung được chấp nhận.
Các cân nhắc về bảo mật xung quanh 406
- Ngăn máy chủ làm rò rỉ các định dạng không mong muốn.
- Giúp tránh các lỗ hổng dò tìm nội dung.
- Có thể được cấu hình để từ chối các định dạng rủi ro như
text/htmltrong API.
Kết luận: Nắm bắt HTTP 406 Not Acceptable để giao tiếp chính xác
Mã trạng thái HTTP 406 Not Acceptable đại diện cho một nguyên tắc quan trọng của kiến trúc web: giao tiếp rõ ràng giữa client và server về khả năng và yêu cầu của chúng. Đó không phải là một lỗi đáng sợ, mà là một cơ chế để đảm bảo rằng việc trao đổi dữ liệu diễn ra ở các định dạng có thể hiểu được lẫn nhau.
Mặc dù bạn có thể không gặp 406 hàng ngày, nhưng việc hiểu nó sẽ khiến bạn trở thành một công dân web tốt hơn. Nó dạy tầm quan trọng của việc rõ ràng về các yêu cầu định dạng dữ liệu và xử lý đàm phán định dạng một cách duyên dáng.
Đối với các nhà phát triển API, việc triển khai đúng cách đàm phán nội dung và các phản hồi 406 dẫn đến các API mạnh mẽ và linh hoạt hơn. Đối với các nhà phát triển client, việc hiểu cách làm việc với lỗi 406 đảm bảo các ứng dụng của bạn có thể thích ứng với các khả năng của máy chủ khác nhau.
Trong một thế giới nơi dữ liệu cần luân chuyển giữa các hệ thống và nền tảng đa dạng, khả năng đàm phán định dạng nội dung có giá trị hơn bao giờ hết. Và khi bạn cần kiểm tra và hoàn thiện các cuộc đàm phán này, một công cụ như Apidog cung cấp môi trường hoàn hảo để đảm bảo các ứng dụng của bạn giao tiếp hiệu quả, bất kể sở thích định dạng.
tải xuống
