Lỗi 406 Not Acceptable và cách kiểm header Accept

lỗi 406 Not Acceptable liên quan tới việc lựa chọn biểu diễn phản hồi phù hợp. Anh em cần kiểm Accept, ngôn ngữ, dạng nén và chính sách của server. Một trang lỗi từ lớp bảo vệ cũng cần được đối chiếu với log trước khi kết luận. ProxyVN hướng dẫn anh em kiểm đúng lớp gây lỗi và giữ bằng chứng trước khi thay cấu hình.

Lỗi 406 Not Acceptable và chiều thương lượng phản hồi

Một URL có thể cung cấp nhiều biểu diễn, chẳng hạn JSON cho ứng dụng và HTML cho trình duyệt. Client gửi các header thương lượng để nói dạng nào nó chấp nhận. Nếu bên nhận không chọn được biểu diễn phù hợp và không muốn gửi phương án mặc định, nó có thể trả 406. Vì thế, bước đầu là xem client đã yêu cầu gì, chứ không chỉ nhìn phần đuôi URL hoặc đổ lỗi cho đường truyền.

MDN mô tả 406 theo hướng lựa chọn phản hồi. Server cũng có thể gửi một biểu diễn mặc định thay vì dùng mã này. Điều đó giải thích vì sao hai API xử lý cùng một Accept không giống nhau. Trong vận hành, phải dựa vào hợp đồng của endpoint và dữ liệu quan sát, không dùng một ca thử làm quy luật cho mọi website.

Accept khác Content Type

Accept trong request mô tả các kiểu đầu ra mà client muốn nhận. Content-Type của request lại mô tả nội dung client đang gửi. Một GET không có body vẫn có thể gặp 406 khi yêu cầu XML từ endpoint chỉ cung cấp JSON. Ngược lại, POST gửi sai định dạng có thể gặp 415 dù Accept hợp lệ. Tách hai chiều này giúp anh em không chữa nhầm header và làm request ngày càng khó hiểu.

Content-Type của response là giá trị cuối cùng mà server chọn gửi. Sau khi hết lỗi 406, client vẫn cần kiểm nó trước khi đưa body vào parser. Nếu nới Accept thành mọi kiểu rồi nhận HTML, chương trình phân tích JSON có thể lỗi ở bước sau. Một trạng thái 200 với trang thông báo cũng chưa đáp ứng hợp đồng dữ liệu. Mục tiêu là nhận biểu diễn mà tác vụ thực sự sử dụng được.

Các chiều thương lượng cần kiểm riêng

Ngoài media type, quá trình thương lượng còn có thể xét ngôn ngữ và content coding. Không nên cùng lúc sửa Accept, Accept-Language và Accept-Encoding rồi kết luận một trường cụ thể gây lỗi. Hãy giữ hai trường còn lại theo mốc đã biết, chỉ đổi một trường trong mỗi ca. Ma trận nhỏ theo từng chiều sẽ giúp thấy lỗi thuộc sở thích của client, cấu hình biểu diễn hay một chính sách khác.

Một header được client khai báo chưa chắc là header tới bộ xử lý cuối. Thư viện, extension, API gateway hoặc lớp cache có thể tham gia. Khi kết quả không khớp, cần so request ở nơi gửi với thông tin tại nơi nhận được phép quan sát. Đừng dùng hình ảnh trang lỗi làm bằng chứng duy nhất, vì một mẫu HTML có thể được nhiều lớp trong cùng hệ thống sử dụng.

Lỗi 406 Not Acceptable khi diễn giải Accept

Giá trị Accept cần được hiểu theo danh sách media range và mức ưu tiên. Một chuỗi chứa nhiều lựa chọn không có nghĩa server bắt buộc hỗ trợ tất cả lựa chọn đó. Nó cần chọn biểu diễn phù hợp với quy tắc và khả năng của endpoint. Với API do anh em quản lý, hãy ghi rõ các media type được hỗ trợ để client có đầu vào ổn định, thay vì phải dò bằng nhiều request.

Giá trị cụ thể và wildcard

Theo tài liệu Accept, client có thể mô tả một kiểu cụ thể hoặc phạm vi rộng hơn. Trong ca cơ sở, một endpoint JSON nên được gọi với application/json. Wildcard có thể hữu ích để kiểm xem yêu cầu hẹp có liên quan tới lỗi không, nhưng không nên trở thành cách che lỗi parser. Nếu công việc cần JSON, kết quả sau thương lượng vẫn phải được xác nhận là JSON.

Một media type dạng vendor có thể được dùng để chọn phiên bản hoặc hợp đồng riêng. Đừng tự thay nó bằng application/json chỉ vì cả hai nội dung trông giống nhau. API có thể dựa vào loại vendor để chọn tuyến xử lý. Tài liệu của dịch vụ mới là nơi xác định giá trị đúng; mẫu từ một API khác chỉ giúp hiểu cách viết header, không thay thế hợp đồng đang áp dụng.

Trọng số và giá trị bằng không

Mức ưu tiên có thể làm client thiên về một biểu diễn, còn trọng số bằng không biểu thị không chấp nhận phạm vi tương ứng. Khi đọc một chuỗi phức tạp, cần xem cả giá trị lẫn mức độ cụ thể của từng mục. Đừng chỉ tìm xem chữ application/json có xuất hiện không. Một quy tắc cụ thể hơn hoặc một giá trị loại trừ có thể ảnh hưởng cách server chọn, nên ca kiểm phải giữ nguyên toàn bộ chuỗi.

Nếu client tự sinh Accept từ cấu hình, ghi lại kết quả cuối thay vì danh sách trong giao diện. Các mục trùng nhau, giá trị không hợp lệ hoặc dấu phân cách sai có thể làm bộ phân tích của server phản hồi khác nhau. Khi điều tra, tạo một giá trị tối giản được tài liệu hỗ trợ, rồi thêm từng lựa chọn trở lại. Không cần dùng một chuỗi mô phỏng trình duyệt dài để gọi API nội bộ chỉ trả một định dạng.

Chiều gửi và chiều nhận

Lỗi 406 Not Acceptable với ngôn ngữ và dạng nén

Media type chỉ là một nhánh. Nếu hệ thống xuất bản nhiều ngôn ngữ hoặc nhiều dạng mã hóa nội dung, kết quả còn tùy các biểu diễn sẵn có. Hướng dẫn content negotiation là tài liệu nền để hiểu các chiều lựa chọn. Trong triển khai, anh em nên dựa vào quy tắc cụ thể của ứng dụng và kiểm từng chiều trên cùng một tài nguyên.

Ngôn ngữ không phải vị trí của proxy

Accept-Language thể hiện ưu tiên ngôn ngữ của client; nó không chứng minh địa chỉ IP thuộc nước nào. Một tài nguyên chỉ có bản tiếng Việt có thể có cách fallback riêng khi client ưu tiên ngôn ngữ khác. Đừng đổi gateway để sửa một danh sách ngôn ngữ bị loại trừ quá chặt. Trước tiên, xác định tài nguyên có những bản nào và server có chấp nhận phản hồi mặc định hay không.

Nếu ứng dụng cho người dùng chọn ngôn ngữ bằng đường dẫn hoặc cookie, hãy kiểm xem cơ chế đó tương tác với header ra sao. Cùng Accept-Language nhưng khác cookie có thể dẫn tới biến thể khác. Mẫu kiểm cần tách thông tin phiên khỏi thông tin thương lượng, nhất là khi một thư viện tái sử dụng cookie jar giữa nhiều tác vụ. Lưu ý này giúp tránh kết luận lỗi xuất hiện ngẫu nhiên trong khi đầu vào thực đã thay đổi.

Dạng nén cần phù hợp khả năng giải mã

Accept-Encoding nói về dạng mã hóa nội dung mà client chấp nhận ở response. Nó khác Content-Encoding của request và cũng khác mã hóa ký tự trong văn bản. Nếu chương trình không có bộ giải nén tương ứng, đừng khai chỉ để giống trình duyệt. Hãy để thư viện quản lý giá trị phù hợp với khả năng của nó, rồi kiểm body đã được giải nén ở lớp nào trước khi đánh giá parser.

Khi thử một server có nhiều dạng nén, cần giữ media type và ngôn ngữ cố định. So giá trị Content-Encoding ở response cùng khả năng đọc dữ liệu cuối. Nếu thư viện tự giải nén nhưng log giữ header cũ, số byte của body trong ứng dụng có thể khác số byte truyền tải. Đây là khác biệt của điểm quan sát, không tự chứng minh dữ liệu bị proxy sửa hoặc hỏng.

Lỗi 406 Not Acceptable trong ma trận endpoint lab

Fixture dưới chỉ cung cấp JSON và chấp nhận đúng hai giá trị minh họa: application/json hoặc wildcard. Nó cố ý không triển khai toàn bộ bộ phân tích Accept, trọng số hay ngôn ngữ. Mục tiêu là tạo đối chứng rõ giữa một yêu cầu phù hợp và một yêu cầu không có biểu diễn đáp ứng. Lưu thành lab406.py rồi chạy trong terminal riêng, chỉ lắng nghe loopback để giới hạn phạm vi thử.

from http.server import BaseHTTPRequestHandler, HTTPServer
 
class API(BaseHTTPRequestHandler):
    def do_GET(self):
        accept = self.headers.get('Accept', '*/*')
        if accept in ('application/json', '*/*'):
            status, body = 200, b'{"format":"json"}'
        else:
            status, body = 406, b'{"available":["application/json"]}'
        self.send_response(status)
        self.send_header('Content-Type', 'application/json')
        self.send_header('Vary', 'Accept')
        self.send_header('Content-Length', str(len(body)))
        self.end_headers()
        self.wfile.write(body)
 
HTTPServer(('127.0.0.1', 8766), API).serve_forever()

Mẫu này trả một danh sách biểu diễn sẵn có trong body lỗi. Đó là lựa chọn của fixture để người đọc dễ hiểu, không phải một schema lỗi chung mà mọi dịch vụ đều dùng. Trong client thật, đọc mô tả lỗi theo tài liệu của API, đừng giả định luôn có trường available. Một trang lỗi HTML cần được lưu như dữ liệu chẩn đoán, không đưa thẳng vào bộ phân tích kết quả thành công.

Gọi ba giá trị rồi so nội dung

curl.exe -i -H "Accept: application/json" http://127.0.0.1:8766/negotiate
curl.exe -i -H "Accept: text/html" http://127.0.0.1:8766/negotiate
curl.exe -i -H "Accept: */*" http://127.0.0.1:8766/negotiate

Trong phép thử cục bộ của bài, cả ba giá trị được gọi trực tiếp và qua forward proxy HTTP. Kết quả lần lượt là 200, 406, 200 trên cả hai đường. Nhánh HTML bị từ chối vì quy tắc của origin, không phải vì gateway cần tài khoản khác. Phép thử không bao gồm thương lượng ngôn ngữ, nén, TLS hay WAF; các nhánh đó cần môi trường riêng để kiểm trước khi công bố kết quả.

Kiểm giới hạn của chính fixture

Nếu gửi một chuỗi có nhiều mục hoặc có trọng số, fixture có thể trả 406 dù một server đầy đủ sẽ tìm được lựa chọn phù hợp. Đây là lý do không dùng mẫu làm bộ thương lượng sản xuất. Khi bổ sung parser, cần có bộ ca cho wildcard, mức ưu tiên, giá trị bị loại trừ và cú pháp sai. Việc mở rộng phải giữ từng tiêu chí rõ ràng để không biến một ví dụ nhỏ thành thư viện HTTP tự viết thiếu kiểm chứng.

Anh em cũng nên thử bỏ Accept và so hành vi mặc định của công cụ. Nếu curl tự thêm wildcard, bản request thực có thể khác với điều anh em nghĩ đã bỏ. Kiểm đầu vào ở server giúp thấy giá trị thực nhận. Với bài kiểm qua proxy, dùng một tên host lab được gateway chuyển tiếp có chủ ý; các địa chỉ loopback có thể bị một số client tự bỏ qua proxy theo quy tắc của thư viện.

Ma trận Accept của endpoint

Lỗi 406 Not Acceptable và cache theo biến thể

Một response được chọn theo header có thể bị cache sai nếu khóa biến thể không phù hợp. Khi chỉ một số người dùng gặp lỗi, kiểm xem họ nhận dữ liệu trực tiếp từ origin hay từ cache. Không nên xóa toàn bộ cache sản xuất ngay từ lần đầu. Hãy chọn một tài nguyên thử và kiểm các header liên quan tới cache cùng thời điểm lấy response, giữ nguyên những giá trị thương lượng trong từng lượt so.

Vai trò của Vary

Tài liệu Vary giải thích cách response chỉ ra các trường request ảnh hưởng việc tái sử dụng biểu diễn. Trong fixture, Vary: Accept giúp thể hiện lựa chọn phụ thuộc Accept. Cấu hình cache thực còn tùy sản phẩm và chính sách của hệ thống. Không coi việc thêm Vary ở ứng dụng là bằng chứng mọi lớp cache phía trước đã xử lý đúng nếu chưa kiểm bằng hai giá trị khác nhau.

Một phép so hữu ích là gọi JSON, gọi HTML rồi gọi JSON lại với cùng tài nguyên thử. Ghi status, Content-Type và thông tin tuổi cache nếu có. Nếu lượt cuối nhận biểu diễn không đúng với đầu vào, điều tra khóa cache hoặc lớp sửa header. Các lượt này phải gắn vào cùng cấu hình và cùng phiên bản ứng dụng, vì một lần triển khai giữa chừng cũng có thể làm kết quả đổi mà không liên quan tới thương lượng.

Cookie và phiên có thể làm phép so lệch

Nếu client dùng cookie để chọn định dạng hoặc vùng nội dung, một header Accept giống nhau chưa tạo đầu vào giống nhau. Hãy ghi sự có mặt của loại cookie liên quan và dùng giá trị thử được phép. Không chia sẻ nguyên cookie phiên trong phiếu hỗ trợ. Với ca công khai không cần đăng nhập, có thể dùng một cookie jar lab riêng để tránh dữ liệu cũ từ các lần gọi trước ảnh hưởng kết quả.

Không nên xóa toàn bộ dữ liệu trình duyệt của người dùng để xem lỗi có hết hay không. Thay vào đó, tách hồ sơ thử hoặc một request không có cookie khi endpoint cho phép. Nếu khác biệt chỉ xuất hiện sau đăng nhập, cần kiểm hợp đồng của biến thể dành cho tài khoản đó. Kết quả từ một cửa sổ mới chỉ giúp khoanh vùng trạng thái phiên, không tự chứng minh cookie cụ thể nào gây lỗi.

Lỗi 406 Not Acceptable khi có WAF hoặc gateway API

Một số hệ thống có thể dùng mã trạng thái theo chính sách riêng. Vì vậy, gặp 406 không đủ để kết luận chỉ cần đổi Accept. Nếu body chứa thông báo của lớp bảo vệ hoặc origin không có dấu vết request, cần kiểm log của thành phần trả lỗi. Hướng điều tra là xác định rule và đầu vào hợp lệ của ứng dụng, không tìm cách lách chính sách bảo vệ đang được vận hành.

Xác định nơi phát sinh trước khi sửa

Giữ thời điểm, request ID và bản rút gọn của request gây lỗi. So với một request hợp lệ tới cùng endpoint trong môi trường được phép. Nếu hai request cùng Accept mà khác một trường nghiệp vụ dẫn tới rule chặn, vấn đề có thể nằm ở chính sách kiểm nội dung. Chỉ người vận hành có log phù hợp mới xác định được rule; tên mã trên màn hình không thay thế việc đối chiếu đó.

Nếu rule chặn nhầm dữ liệu hợp lệ, gửi mẫu tối giản đã che bí mật cho bên quản lý để họ xem xét điều chỉnh đúng phạm vi. Không tắt WAF toàn site chỉ để giải quyết một tuyến. Một thay đổi hẹp theo endpoint và điều kiện cụ thể có thể được kiểm trước và sau. Lưu cả ca dữ liệu hợp lệ lẫn ca cần chặn để tránh bản sửa mở rộng phạm vi ngoài mục tiêu ban đầu.

Không đổi nhiều header để giả lập một trình duyệt

Sao chép một bộ header dài từ trình duyệt có thể làm request thành công nhưng không cho biết lý do. Nó còn mang theo cookie, token hoặc giá trị chỉ có ý nghĩa trong phiên gốc. Với API, hãy bắt đầu bằng header được tài liệu yêu cầu. Nếu website có luồng truy cập riêng cho trình duyệt, sử dụng giao diện hoặc API được cấp quyền thay vì coi bộ header sao chép là một hợp đồng ổn định.

Một thay đổi User-Agent trùng với lúc lỗi biến mất vẫn cần đối chứng. Có thể cache đã hết hạn, tác vụ nền đã hoàn thành hoặc server vừa thay cấu hình. Hãy so các lượt trong môi trường kiểm soát và ghi điều chưa xác định. Điều này giữ báo cáo kỹ thuật có giá trị, tránh biến một lần thử tình cờ thành lời hứa rằng mọi mã 406 đều được sửa bằng một giá trị header cố định.

Cache theo biến thể

Lỗi 406 Not Acceptable trong quy trình xử lý dữ liệu

Client nên có hợp đồng đầu ra rõ: chấp nhận những media type nào và xử lý từng kiểu ra sao. Khi nhận 406, lưu lý do cùng tác vụ rồi dừng retry tức thời nếu đầu vào không đổi. Nếu API liệt kê biểu diễn khác, chỉ chọn biểu diễn mà chương trình có parser phù hợp. Không nhận bất kỳ dữ liệu nào chỉ để chuyển trạng thái tác vụ thành thành công trong dashboard.

Cấu hình theo endpoint thay vì một giá trị chung

Một worker gọi nhiều dịch vụ nên có cấu hình thương lượng theo endpoint hoặc nhóm API có cùng hợp đồng. API ảnh, API JSON và tuyến xuất CSV không nên dùng chung một chuỗi Accept được sao chép vì tiện. Mỗi cấu hình cần có ví dụ phản hồi hợp lệ và parser tương ứng. Khi thêm dịch vụ mới, kiểm một tài nguyên nhỏ trước để tránh gửi nhầm kỳ vọng tới toàn bộ lô dữ liệu.

Nếu dịch vụ có phiên bản media type, gắn cấu hình đó với phiên bản client. Khi nâng SDK, so request đã chuẩn bị và response đã chọn trước khi đưa vào worker chính. Một thay đổi mặc định trong thư viện có thể làm Accept rộng hơn hoặc khác dạng, dù mã gọi không sửa. Theo dõi lỗi theo phiên bản giúp khoanh vùng producer gây khác biệt nhanh hơn một tổng số 406 trên toàn hệ thống.

Điều kiện nghiệm thu bản sửa

Bản sửa đạt khi request được chấp nhận và dữ liệu đầu ra có kiểu, schema, ngôn ngữ hoặc dạng nén mà tác vụ cần. Nếu chương trình nhận CSV rồi lưu như JSON, lỗi chỉ bị đẩy sang bước khác. Nên kiểm một trường đặc trưng trong response, không chỉ kiểm status. Với dữ liệu phân trang, kiểm thêm trang tiếp theo vì URL hoặc cấu hình request của nó có thể được tạo bằng một nhánh khác.

Một ca lỗi hữu ích cần được giữ trong kiểm thử hồi quy. Ví dụ, endpoint JSON với Accept HTML phải trả hành vi đã công bố, còn Accept JSON phải trả dữ liệu có thể parse. Nếu server chọn fallback thay vì 406, kiểm đúng fallback đó. Mục tiêu của hồi quy là bảo vệ hợp đồng ứng dụng, không bắt mọi server dùng cùng một mã vì ví dụ trong bài đã chọn như vậy.

Lỗi 406 Not Acceptable và hồ sơ bàn giao

Phiếu hỗ trợ nên có URL đã bỏ dữ liệu nhạy cảm, method, chuỗi Accept thực gửi, các chiều thương lượng liên quan và mẫu response rút gọn. Ghi client cùng phiên bản và chỉ rõ có qua gateway hay không. Khi cần kiểm đầu vào mạng, anh em có thể xem định dạng proxy; nếu có bypass, đối chiếu cách dùng no_proxy để biết lượt nào thật sự qua điểm đang quan sát.

Bài tập kiểm thêm mà không làm lệch mục tiêu

Hãy lập một bảng với từng cột là media type, ngôn ngữ, dạng nén và trạng thái phiên. Mỗi hàng chỉ đổi một cột so với ca cơ sở; ghi status và kiểu nội dung cuối. Với fixture trong bài, chỉ cột media type được triển khai, nên các cột còn lại phải ghi chưa kiểm thay vì tự điền thành công. Với ứng dụng thật, bảng đó cho thấy phần nào thuộc hợp đồng đã xác nhận và phần nào cần kiểm tiếp.

Nếu cần mở rộng fixture, thêm một tài nguyên HTML riêng thay vì âm thầm đổi hành vi của tài nguyên JSON đang dùng để hồi quy. Tài nguyên mới có thể giúp kiểm cách client chọn parser theo Content-Type. Sau đó thêm trường hợp server chọn phản hồi mặc định, ghi rõ đây là chính sách mới của lab. Việc giữ các mốc độc lập giúp người đọc hiểu tác động của từng thay đổi và không nhầm sửa fixture với sửa client.

Phân trang cần giữ cùng kỳ vọng đầu ra

Một API có thể trả URL trang tiếp theo, còn client tạo request mới bằng một nhánh mã khác. Nếu nhánh đó không giữ Accept hoặc cấu hình phiên cần thiết, trang đầu thành công nhưng trang sau lại gặp 406. Ca kiểm tích hợp nên đi qua ít nhất một bước phân trang bằng dữ liệu lab, xác nhận các header có ý nghĩa được áp đúng. Không sao chép mọi header từ response thành request; chỉ giữ những trường thuộc hợp đồng client phải gửi.

Nếu URL phân trang chuyển sang host khác, kiểm quy tắc truyền credential riêng trước khi tiếp tục. Một Accept đúng không cho phép gửi token của host cũ tới đích tùy ý. Với API công bố một host dữ liệu khác, cấu hình theo tài liệu và dùng tài khoản lab. Phép kiểm cần giữ cả biểu diễn đầu ra lẫn ranh giới danh tính; sửa lỗi thương lượng mà làm lộ credential không phải một kết quả đạt yêu cầu của hệ thống.

Hợp đồng parser cần rõ về biến thể

Khi client hỗ trợ nhiều kiểu đầu ra, nên có parser tương ứng và kiểm chọn parser dựa trên dữ kiện được hợp đồng cho phép. Nếu JSON và CSV có các trường hoặc kiểu giá trị khác nhau, quá trình chuẩn hóa phải được kiểm bằng cùng bộ dữ liệu mẫu. Không nhận CSV rồi chia chuỗi theo dấu phẩy một cách tùy tiện nếu định dạng có quoting hoặc xuống dòng trong ô. Việc nới Accept chỉ hợp lý khi cả quá trình xử lý biểu diễn mới đã được chuẩn bị.

Với ngôn ngữ, giữ các trường định danh không phụ thuộc bản dịch để việc gộp dữ liệu không bị thay đổi khi fallback xảy ra. Một nhãn hiển thị khác không phải tài nguyên khác nếu API có ID ổn định, nhưng cũng không nên tự giả định ID luôn có mặt. Kiểm schema của từng biểu diễn và ghi rõ phần dữ liệu mà sản phẩm cần. Điều kiện nghiệm thu nên tập trung vào thông tin sử dụng được, thay vì chỉ một chuỗi header trông giống mẫu của trình duyệt.

Kiểm giá trị loại trừ trong môi trường đầy đủ

Khi có server triển khai parser Accept đầy đủ, bổ sung ca trọng số bằng không và ca lựa chọn cụ thể hơn wildcard. Ghi kết quả theo chính sách endpoint đã công bố và kiểm nội dung cuối. Fixture đơn giản của bài không được dùng để kết luận các ca này, vì nó chỉ so chuỗi theo hai giá trị cơ sở. Ranh giới đó giúp người đọc biết phần nào đã có kết quả thực và phần nào cần một công cụ thương lượng phù hợp hơn để kiểm.

Một phản hồi hết mã 406 chỉ có ích khi biểu diễn nhận được phù hợp với cách chương trình xử lý.

Kiểm đầu ra sau thương lượng

Trước khi mua proxy cho quy trình lấy dữ liệu được phép, anh em nên kiểm giao thức và cách xác thực của đường mạng. Cấu hình gateway cần được đánh giá riêng với chính sách lựa chọn biểu diễn của endpoint; thay đường truyền không thay hợp đồng đầu ra mà client yêu cầu.

Anh em nên giữ request mẫu, kết quả đối chứng và cấu hình đã che thông tin nhạy cảm để kiểm lại sau thay đổi. Theo dõi Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam để tham khảo nội dung liên quan. Khi triển khai, đánh giá đúng phạm vi của lỗi 406 Not Acceptable.