Blog

Mã trạng thái 417 Expectation Failed là gì? Lỗi bắt tay

INEZA Felin-Michel

INEZA Felin-Michel

15 tháng 10 2025

Mã trạng thái 417 Expectation Failed là gì? Lỗi bắt tay

Apidog cho doanh nghiệp

Triển khai tại chỗ

SSO & RBAC

Tuân thủ SOC 2

Khám phá Apidog Enterprise

Bạn đang ở một nhà hàng với những yêu cầu ăn uống đặc biệt. Ngay cả trước khi gọi món, bạn đã nói với người phục vụ, "Tôi sẽ chỉ ăn ở đây nếu nhà bếp có thể đảm bảo không có gluten." Người phục vụ kiểm tra với nhà bếp và quay lại nói, "Tôi xin lỗi, chúng tôi không thể đáp ứng yêu cầu đó." Bữa ăn thậm chí còn chưa được gọi. Việc kiểm tra sơ bộ này và sự thất bại của nó chính là ý nghĩa của mã trạng thái HTTP **417 Expectation Failed**.

417 là một trong những mã trạng thái HTTP ít được biết đến hơn. Nó không liên quan đến các trang bị thiếu, vấn đề xác thực hay lỗi máy chủ. Thay vào đó, nó xử lý một loại đàm phán thất bại rất cụ thể giữa máy khách và máy chủ ngay từ đầu cuộc hội thoại của họ.

Đó là cách máy chủ nói, "Bạn đã đặt ra một điều kiện tiên quyết mà tôi không thể đáp ứng, vì vậy tôi thậm chí sẽ không cố gắng xử lý yêu cầu chính của bạn."

Nếu bạn là nhà phát triển làm việc với máy chủ web hoặc xây dựng máy khách HTTP, việc hiểu mã hiếm này sẽ cung cấp cái nhìn sâu sắc thú vị về thiết kế giao thức để giao tiếp hiệu quả.

💡
Nếu bạn đang xây dựng hoặc kiểm thử API và muốn đảm bảo giao tiếp máy khách-máy chủ diễn ra suôn sẻ, bạn cần một công cụ có thể xử lý tất cả các loại tương tác HTTP. **Tải xuống Apidog miễn phí**; đây là một nền tảng API tất cả trong một giúp bạn tạo các yêu cầu chính xác và hiểu phản hồi của máy chủ, giúp việc gỡ lỗi ngay cả những mã trạng thái khó hiểu nhất trở nên dễ dàng hơn.

nút

Để hiểu đầy đủ cách điều này xảy ra, tại sao nó quan trọng và phải làm gì với nó, hãy cùng đi sâu vào chi tiết từng bước một.

Vấn đề: Lãng phí băng thông cho các yêu cầu thất bại

Để hiểu tại sao 417 tồn tại, chúng ta cần quay trở lại những ngày đầu của web khi băng thông còn quý giá và kết nối chậm. Hãy tưởng tượng một máy khách cần tải lên một tệp lớn lên máy chủ, nhưng nó muốn đảm bảo máy chủ có thể xử lý tệp đó trước. Nếu không có kiểm tra sơ bộ, cuộc trò chuyện có thể diễn ra như sau:

  1. Máy khách: (Gửi tệp 100MB) "Đây là dữ liệu của tôi!"
  2. Máy chủ: (Sau khi nhận toàn bộ tệp) "Xin lỗi, tệp quá lớn. Tôi chỉ có thể chấp nhận tệp có kích thước tối đa 50MB."
  3. Kết quả: 100MB băng thông bị lãng phí cho một yêu cầu đã thất bại ngay từ đầu.

Tiêu đề Expect và mã trạng thái 417 được thiết kế để ngăn chặn chính xác kịch bản lãng phí này.

Mã trạng thái HTTP 417 Expectation Failed thực sự có nghĩa là gì?

Mã trạng thái 417 Expectation Failed cho biết máy chủ không thể đáp ứng các yêu cầu của trường tiêu đề yêu cầu Expect. Về cơ bản, máy khách đã nói, "Tôi mong bạn có thể làm X," và máy chủ trả lời, "Tôi không thể làm X, vì vậy tôi sẽ không xử lý yêu cầu của bạn."

Giá trị phổ biến nhất và trong một thời gian dài, là giá trị duy nhất cho tiêu đề Expect là 100-continue.

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

HTTP/1.1 417 Expectation FailedContent-Type: text/htmlContent-Length: 125
<html><head><title>417 Expectation Failed</title></head><body><center><h1>417 Expectation Failed</h1></center></body></html>

Đối với API, nó có thể bao gồm một phần thân JSON hữu ích hơn:

HTTP/1.1 417 Expectation FailedContent-Type: application/json
{
  "error": "ExpectationFailed",
  "message": "Server does not support the Expect header condition",
  "code": 417
}

Giao thức bắt tay Expect: 100-continue

Để thực sự hiểu 417, chúng ta cần xem xét cách sử dụng nổi tiếng nhất của tiêu đề Expect: Expect: 100-continue. Điều này tạo ra một quy trình yêu cầu hai bước được thiết kế để ngăn chặn lãng phí băng thông.

Kịch bản lạc quan (Thành công)

Máy khách gửi tiêu đề: Máy khách gửi các tiêu đề yêu cầu với Expect: 100-continue, nhưng giữ lại phần thân yêu cầu.

POST /upload HTTP/1.1Host: example.comContent-Type: application/octet-streamContent-Length: 104857600  # 100MBExpect: 100-continue

(Lưu ý là chưa có phần thân)

Máy chủ phản hồi 100 Continue: Máy chủ kiểm tra xem nó có thể xử lý yêu cầu hay không (ví dụ: có đủ dung lượng, chấp nhận loại nội dung). Nếu có, nó sẽ phản hồi:

HTTP/1.1 100 Continue

Máy khách gửi phần thân: Máy khách nhận được 100 Continue và bây giờ gửi phần thân tệp 100MB.

Phản hồi cuối cùng của máy chủ: Máy chủ xử lý yêu cầu hoàn chỉnh và phản hồi với trạng thái cuối cùng (ví dụ: 201 Created).

Kịch bản 417 (Thất bại)

Máy khách gửi tiêu đề: Yêu cầu ban đầu tương tự với Expect: 100-continue.

Phản hồi 417 của máy chủ: Máy chủ xác định rằng nó không thể thực hiện kỳ vọng (ví dụ: tệp quá lớn, loại nội dung không được hỗ trợ).

HTTP/1.1 417 Expectation FailedContent-Type: application/json
{"error": "File size exceeds 50MB limit"}

Máy khách dừng lại: Máy khách không bao giờ gửi phần thân 100MB, tiết kiệm đáng kể băng thông và thời gian.

Tại sao lỗi 417 "Expectation Failed" xảy ra?

Hãy cùng bóc tách các lớp. Nguyên nhân chính của lỗi 417 là việc sử dụng **tiêu đề yêu cầu Expect**, đặc biệt là Expect: 100-continue. Đặc tả HTTP/1.1 cho phép máy khách gửi tiêu đề này để giảm truyền dữ liệu không cần thiết. Đây là cách nó hoạt động trên lý thuyết:

  1. Máy khách gửi một yêu cầu với các tiêu đề **bao gồm** Expect: 100-continue, nhưng *chưa có phần thân*.
  2. Máy chủ kiểm tra các tiêu đề. Nếu máy chủ đồng ý nhận phần thân (dựa trên các yếu tố như tiêu đề, xác thực, phương thức), nó sẽ phản hồi với trạng thái **100 Continue** về cơ bản là “Được rồi, tiếp tục, gửi phần thân của bạn.”
  3. Sau đó, máy khách gửi phần thân yêu cầu thực tế (ví dụ: tải tệp lên hoặc tải trọng JSON lớn).
  4. Máy chủ hoàn tất quá trình xử lý và trả về phản hồi cuối cùng (ví dụ: 200, 201, v.v.).

Tuy nhiên, đôi khi mọi thứ không suôn sẻ:

Khi điều đó xảy ra, thay vì gửi 100 Continue, máy chủ có thể phản hồi bằng **417 Expectation Failed**, nói với máy khách "Tôi không thể tuân thủ kỳ vọng mà bạn đã yêu cầu."

Theo tài liệu của MDN:

Mã trạng thái lỗi máy khách HTTP 417 Expectation Failed cho biết kỳ vọng được đưa ra trong tiêu đề Expect của yêu cầu không thể được đáp ứng. MDN Web Docs
Expect

Các nguồn khác cũng lặp lại điều này: lỗi 417 phát sinh khi máy chủ không hỗ trợ các kỳ vọng (hoặc kỳ vọng cụ thể đó) nhưng máy khách vẫn bao gồm một kỳ vọng.

Vì vậy, nó thường không phải là về “tải trọng của bạn sai,” mà là “tiêu đề kỳ vọng của bạn không được chấp nhận.”

Tại sao một số máy chủ từ chối kỳ vọng

Không phải tất cả các máy chủ hoặc bên trung gian đều hỗ trợ giao thức bắt tay kỳ vọng này. Một số lý do bao gồm:

Nếu máy chủ không thể hoặc sẽ không phản hồi với 100 Continue, nhưng máy khách mong đợi điều đó (tức là tiêu đề Expect có mặt), sự không khớp đó sẽ kích hoạt **417 Expectation Failed**.

Vì lý do đó, giải pháp thường đơn giản: **không gửi Expect**  hoặc xóa nó khi có nghi ngờ về khả năng tương thích.

Tại sao bạn hiếm khi thấy lỗi 417 trong thực tế

Mặc dù là một ý tưởng thông minh, mã trạng thái 417 ngày nay cực kỳ hiếm gặp. Đây là lý do:

1. Hỗ trợ máy chủ không nhất quán

Nhiều máy chủ web và framework ứng dụng chưa bao giờ triển khai hỗ trợ đúng cách cho giao thức bắt tay Expect: 100-continue. Khi nhận được tiêu đề này, họ thường bỏ qua nó và xử lý yêu cầu bình thường, hoặc trả về lỗi như 400 Bad Request.

2. Sự phức tạp phía máy khách

Việc triển khai giao thức bắt tay hai bước làm tăng độ phức tạp cho các máy khách HTTP. Chúng cần phải:

Nhiều thư viện máy khách đã đơn giản hóa việc triển khai của họ bằng cách không sử dụng Expect: 100-continue chút nào.

3. Sự phát triển của mạng nhanh hơn

Khi tốc độ internet tăng lên, việc tiết kiệm băng thông từ việc tránh một lần tải lên lớn trở nên ít quan trọng hơn đối với nhiều ứng dụng. Sự phức tạp đã lớn hơn lợi ích đối với các trường hợp sử dụng phổ biến.

4. Các phương pháp tiếp cận thay thế

Các nhà phát triển đã tìm ra những cách khác để giải quyết cùng một vấn đề:

Cấu trúc của một phản hồi 417

Khi một máy chủ trả về **417 Expectation Failed**, phản hồi trông như thế nào? Hãy xem xét các yếu tố điển hình:

Dòng trạng thái:

HTTP/1.1 417 Expectation Failed

Tiêu đề:

Có thể bao gồm Content-Type, Content-Length, và có thể là một phần thân giải thích lỗi (HTML hoặc JSON).

Nó thường *không* bao gồm 100 Continue vì đây là một phản hồi cuối cùng từ chối kỳ vọng.

Nó cũng có thể bao gồm các tiêu đề máy chủ hoặc chẩn đoán (ví dụ: Server, Date).

Phần thân (tùy chọn):

Thường là một trang lỗi đơn giản hoặc phần thân JSON thông báo cho máy khách rằng kỳ vọng đã thất bại.

Ví dụ (đơn giản hóa):

HTTP/1.1 417 Expectation Failed
Content-Type: text/plain
Content-Length: 25

Expectation not supported

Phần thân có thể khác nhau. Quan trọng là, sau lỗi 417, máy khách nên thử lại mà không có `Expect`.

Các kịch bản phổ biến khi & nơi bạn sẽ thấy lỗi 417

Hãy cùng xem xét một số kịch bản thực tế mà lỗi 417 có thể xuất hiện. Nhận biết các mẫu giúp bạn gỡ lỗi nhanh hơn.

Kịch bản 1: Tải tệp lên hoặc API PUT/POST với Expect: 100-continue

Bạn đang tải lên một tệp hoặc gửi một JSON lớn qua PUT hoặc POST, và máy khách HTTP hoặc framework của bạn tự động thêm Expect: 100-continue. Máy chủ không hỗ trợ giao thức bắt tay đó, vì vậy nó trả về 417. Máy khách thường thấy điều này khi thực hiện các cuộc gọi HTTP từ .NET, Java, v.v.

Ví dụ, một số chủ đề trên StackOverflow chỉ ra rằng `HttpWebRequest` của .NET đặt `Expect: 100-continue` theo mặc định, và nếu máy chủ từ chối nó, bạn sẽ thấy lỗi 417.

Kịch bản 2: Sự can thiệp của Proxy hoặc Middleware

Ngay cả khi máy chủ gốc của bạn hỗ trợ các kỳ vọng, một proxy hoặc bộ cân bằng tải trung gian có thể không. Proxy đó có thể loại bỏ tiêu đề hoặc từ chối nó, gây ra lỗi 417 trước khi yêu cầu của bạn đến ứng dụng.

Kịch bản 3: Máy chủ hoặc API Gateway bị cấu hình sai

Máy chủ của bạn (hoặc API gateway phía trước) bị cấu hình sai liên quan đến hỗ trợ kỳ vọng. Ví dụ, nó có thể từ chối rõ ràng `Expect` hoặc thiếu logic để phân tích cú pháp nó. Đôi khi, các đường dẫn mã trong máy chủ phản hồi các tiêu đề không mong muốn bằng các lỗi chung như 417.

Kịch bản 4: Sử dụng thư viện hoặc cài đặt mặc định của Framework

Một số framework hoặc SDK thêm `Expect` theo mặc định. Nếu máy chủ của bạn không hỗ trợ nó, bạn sẽ thấy lỗi 417. Trong một số môi trường .NET, mọi người đặt `ServicePointManager.Expect100Continue = false` để tắt hành vi mặc định.

Kịch bản 5: Công cụ kiểm thử hoặc Máy khách HTTP

Bạn có thể kiểm thử bằng Postman, cURL hoặc Apidog. Nếu bạn đặt rõ ràng tiêu đề `Expect` (hoặc nếu công cụ tự động làm điều đó), bạn có thể nhận được lỗi 417 khi kiểm thử, ngay cả khi trong thực tế sử dụng bạn không bao gồm tiêu đề đó.

Các trường hợp sử dụng hiện đại và sự trở lại

Mặc dù hiếm, tiêu đề `Expect` và trạng thái `417` đang tìm thấy sức sống mới trong các ngữ cảnh cụ thể:

1. Giới hạn tốc độ API

Một số API sử dụng kiểm tra kỳ vọng tùy chỉnh:

GET /api/data HTTP/1.1Expect: ratelimit=1000

Nếu máy khách vượt quá giới hạn tốc độ của họ, máy chủ có thể phản hồi bằng `417 Expectation Failed` thay vì xử lý yêu cầu và sau đó trả về `429 Too Many Requests`.

2. Đàm phán tính năng

API có thể sử dụng các kỳ vọng tùy chỉnh để hỗ trợ tính năng:

POST /api/process HTTP/1.1Expect: features=ml-prediction,image-recognition

Nếu máy chủ không hỗ trợ các tính năng này, nó có thể trả về `417` với thông tin chi tiết về những gì nó có thể hỗ trợ.

3. Xác thực tài nguyên

Kiểm tra xem các tài nguyên cần thiết có sẵn hay không trước khi xử lý một yêu cầu phức tạp.

Kiểm thử luồng Expect/Continue với Apidog

Giao diện người dùng mới của Apidog 4

Kiểm thử giao thức bắt tay `Expect: 100-continue` thủ công khá khó khăn, đó là một lý do khác khiến nó hiếm khi được sử dụng. **Apidog** làm cho quá trình này dễ quản lý hơn nhiều.

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

  1. Tạo tiêu đề Expect: Dễ dàng thêm `Expect: 100-continue` hoặc các tiêu đề kỳ vọng tùy chỉnh vào yêu cầu của bạn.
  2. Mô phỏng quy trình hai bước: Apidog có thể xử lý yêu cầu chỉ có tiêu đề ban đầu và chờ phản hồi tạm thời của máy chủ.
  3. Kiểm thử tuân thủ máy chủ: Xác minh xem máy chủ của bạn có triển khai đúng giao thức bắt tay Expect/Continue hay không bằng cách kiểm tra xem nó có trả về `100 Continue`, `417 Expectation Failed` hay bỏ qua hoàn toàn tiêu đề.
  4. Gỡ lỗi các kỳ vọng tùy chỉnh: Nếu bạn đang triển khai logic kỳ vọng tùy chỉnh trong API của mình, hãy sử dụng Apidog để kiểm thử các kịch bản khác nhau và đảm bảo phản hồi `417` của bạn bao gồm thông tin lỗi hữu ích.
  5. So sánh các phương pháp tiếp cận: Kiểm thử cùng một lần tải lên có và không có `Expect: 100-continue` để xem sự khác biệt về hiệu suất trong trường hợp sử dụng cụ thể của bạn.

nút

Bằng cách lặp lại theo cách này, Apidog cung cấp cho bạn phản hồi nhanh chóng khi bạn điều chỉnh hành vi của máy khách hoặc máy chủ.

Cách khắc phục hoặc tránh lỗi 417

Sau khi được chẩn đoán, làm thế nào để bạn khắc phục lỗi 417 và ngăn chặn nó trong tương lai? Dưới đây là các giải pháp và thực tiễn tốt nhất.

Xóa hoặc tắt tiêu đề Expect phía máy khách

Nếu có thể, đừng gửi Expect: 100-continue chút nào. Nhiều máy khách cho phép bật/tắt điều này:

Bằng cách gửi một yêu cầu đơn giản, bạn tránh hoàn toàn việc kích hoạt giao thức bắt tay kỳ vọng.

Cấu hình máy chủ để chấp nhận các kỳ vọng

Nếu bạn kiểm soát máy chủ, bạn có thể thử hỗ trợ giao thức bắt tay `Expect`:

Tuy nhiên, việc hỗ trợ các kỳ vọng làm tăng độ phức tạp; nhiều tác giả máy chủ chọn cách từ chối hoặc bỏ qua tiêu đề đó thay vì triển khai đầy đủ.

Sử dụng logic dự phòng

Nếu bạn nhận được lỗi 417, logic máy khách của bạn nên:

  1. Bắt phản hồi 417
  2. Thử lại cùng một yêu cầu *mà không có* tiêu đề `Expect` và gửi phần thân ngay lập tức
  3. Tiếp tục xử lý phản hồi

Điều này đảm bảo rằng ngay cả khi ngữ nghĩa kỳ vọng thất bại, yêu cầu của bạn vẫn được thực hiện.

Xem xét Middleware, Proxies & Gateways

Đảm bảo rằng không có bên trung gian nào (proxy, bộ cân bằng tải, gateway) loại bỏ hoặc hiểu sai tiêu đề `Expect`. Nếu có, bạn có thể cần điều chỉnh cấu hình hoặc nâng cấp phiên bản.

Ghi nhớ các phiên bản và đặc tả HTTP

Đảm bảo máy chủ HTTP và bất kỳ proxy nào của bạn hỗ trợ đúng các tính năng HTTP/1.1. Đảm bảo cơ sở hạ tầng của bạn không hạ cấp hoặc hiểu sai các tiêu đề yêu cầu.

Tài liệu hóa hành vi & Hợp đồng API

Trong tài liệu API của bạn, hãy ghi chú liệu các tiêu đề `Expect` có được hỗ trợ hay không và khuyến nghị máy khách không gửi chúng (nếu bạn không hỗ trợ). Tài liệu rõ ràng giúp giảm sự nhầm lẫn và lỗi phía máy khách.

Giám sát & Cảnh báo về lỗi 417

Thiết lập giám sát để phát hiện tỷ lệ lỗi 417 cao. Nếu một ứng dụng máy khách hoặc một lô đang kích hoạt nhiều lỗi 417, đó là dấu hiệu của cấu hình sai hoặc hành vi máy khách không tương thích.

Các thực tiễn tốt nhất cho phát triển hiện đại

Nếu bạn đang xây dựng một máy chủ:

Nếu bạn đang xây dựng một máy khách:

Đối với hầu hết các ứng dụng:

Những cạm bẫy, hiểu lầm & mẹo phổ biến

Dưới đây là một số điều cần lưu ý và làm rõ:

  1. Hiểu lầm: 417 có nghĩa là phần thân sai: Không, 417 là về các kỳ vọng (tiêu đề), không phải nội dung tải trọng.
  2. Lạm dụng 417 cho lỗi xác thực: Không sử dụng 417 khi một lược đồ JSON hoặc xác thực thất bại. Thay vào đó, hãy sử dụng 400, 422 hoặc các mã 4xx thích hợp.
  3. Giả định tất cả các máy chủ đều hỗ trợ `Expect`: Nhiều máy chủ, proxy hoặc lớp CDN không hỗ trợ. Đừng dựa vào ngữ nghĩa kỳ vọng trừ khi bạn kiểm soát toàn bộ ngăn xếp.
  4. Bỏ qua proxy & middleware: Ngay cả khi máy chủ gốc của bạn hỗ trợ `Expect`, cơ sở hạ tầng phía trên có thể làm hỏng nó.
  5. Bỏ qua logic dự phòng: Luôn lên kế hoạch để máy khách thử lại mà không có `Expect`.
  6. Loại bỏ `Expect` một cách mù quáng ở mọi nơi: Nếu một số máy chủ có hỗ trợ `Expect` và giao thức bắt tay giúp ích (ví dụ: trong việc chấp nhận có điều kiện tải trọng lớn), việc loại bỏ nó một cách phổ biến có thể làm giảm hiệu quả. Hãy sử dụng một cách thận trọng.
  7. Thiếu tài liệu: Nếu API của bạn không tài liệu hóa hỗ trợ kỳ vọng (hoặc thiếu hỗ trợ), các nhà phát triển máy khách có thể bị nhầm lẫn khi lỗi 417 xuất hiện.
  8. Không giám sát tỷ lệ lỗi 417: Nếu một máy khách hoặc tích hợp kích hoạt nhiều lỗi 417, nó có thể che giấu một lỗi sâu hơn trong cách chúng tạo yêu cầu.

Tại sao việc hiểu lỗi 417 lại quan trọng trong các hệ thống thực tế

Bạn có thể nghĩ lỗi 417 hiếm gặp, vậy tại sao phải quan tâm? Nhưng có những lý do chính đáng:

  1. Khả năng tương tác tốt hơn: API của bạn có thể được nhiều máy khách (ứng dụng của bên thứ ba, SDK di động) sử dụng. Nếu một số sử dụng `Expect` và bạn từ chối chúng, chúng sẽ thất bại trừ khi bạn xử lý nó một cách khéo léo.
  2. Xử lý tải trọng lớn hiệu quả: Giao thức bắt tay `Expect: 100-continue` nhằm tránh gửi các phần thân lớn khi máy chủ sẽ từ chối chúng. Nếu bạn hỗ trợ nó đúng cách, điều đó có thể tiết kiệm băng thông và độ trễ.
  3. Xử lý lỗi & gỡ lỗi minh bạch: Lỗi 417 truyền đạt chính xác *lý do* máy chủ từ chối yêu cầu (không khớp kỳ vọng). Điều đó cung cấp nhiều thông tin hơn là một "lỗi nội bộ 500" mơ hồ.
  4. Độ tin cậy trong sản xuất: Trong các trường hợp đặc biệt (ví dụ: tải tệp lớn, chuỗi proxy, cập nhật tăng dần), logic kỳ vọng có thể thất bại bất ngờ. Biết cách xác định và giảm thiểu lỗi 417 giúp ngăn chặn các lỗi tiềm ẩn.
  5. Tác động đến SEO và lập chỉ mục: Mặc dù 417 là lỗi máy khách, nhưng nếu các bot thu thập dữ liệu hoặc công cụ giám sát gặp lỗi 417 trên các điểm cuối quan trọng, các trang kết quả có thể bị hủy lập chỉ mục hoặc bị gắn cờ. Một bài viết lưu ý rằng phản hồi 417 có thể khiến các công cụ thu thập dữ liệu bỏ qua các trang.
  6. Trải nghiệm nhà phát triển: Các máy khách gặp lỗi 417 sẽ dễ dàng chẩn đoán “không khớp kỳ vọng tiêu đề” hơn nếu thông báo lỗi và dự phòng của bạn rõ ràng.

Mối quan hệ với các mã trạng thái khác

Sẽ hữu ích khi hiểu cách `417` liên quan đến các mã lỗi máy khách khác:

Kết luận: Một giải pháp thích hợp đang chờ thời cơ

Mã trạng thái HTTP `417 Expectation Failed` đại diện cho một tối ưu hóa thông minh nhưng chưa bao giờ đạt được sự chấp nhận rộng rãi. Đó là một giải pháp cho một vấn đề thực sự nhằm ngăn chặn lãng phí băng thông cho các yêu cầu thất bại, cuối cùng đã bị bỏ qua bởi tiến bộ công nghệ và các phương pháp tiếp cận thay thế.

Tuy nhiên, nó vẫn tồn tại trong đặc tả HTTP, một minh chứng cho thiết kế toàn diện của giao thức. Đối với một số ứng dụng chuyên biệt, đặc biệt là những ứng dụng liên quan đến truyền dữ liệu lớn qua mạng bị hạn chế, giao thức bắt tay Expect/Continue và tín hiệu thất bại `417` của nó vẫn có thể mang lại hiệu quả đáng kể.

Hiểu `417` mang lại cho bạn cái nhìn sâu sắc hơn về triết lý thiết kế của HTTP và sự phát triển không ngừng của các tiêu chuẩn web. Mặc dù bạn có thể không bao giờ cần tự mình triển khai nó, nhưng việc biết nó tồn tại sẽ khiến bạn trở thành một nhà phát triển web có kiến thức hơn.

Đối với phần lớn công việc API của bạn, bạn sẽ tập trung vào các mã trạng thái phổ biến hơn. Và khi bạn cần kiểm thử và đảm bảo API của mình xử lý tất cả các kịch bản có thể một cách chính xác, một công cụ như **Apidog** cung cấp nền tảng kiểm thử toàn diện mà bạn cần để xây dựng các dịch vụ web mạnh mẽ, đáng tin cậy.

nút

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