Lỗi 417 Expectation Failed: tìm hop từ chối Expect

Lỗi 417 Expectation Failed là mã HTTP báo rằng máy chủ hoặc một hop ở giữa không đáp ứng được kỳ vọng ghi trong header Expect của request. Trong thực tế gần như luôn liên quan tới Expect: 100-continue, header mà curl và nhiều thư viện tự thêm khi upload dữ liệu lớn. ProxyVN dựng một máy chủ đích và ba proxy tự viết trên máy lab, rồi gửi upload 2 KB, 2 MB và 5 MB bằng curl 8.13.0 qua từng proxy. Kết quả cho thấy hop nào trả 417 và hop nào làm upload chậm thêm đúng một giây.

Lỗi 417 Expectation Failed: lớp nào quyết định hành vi

Header Expect cho phép client nói trước với máy chủ: tôi sẽ gửi một thân request lớn, hãy cho tôi biết có nhận không trước khi tôi gửi. Máy chủ đồng ý bằng phản hồi tạm 100 Continue. Máy chủ từ chối bằng mã cuối như 413 hay 401, và client khỏi phải gửi thân.

Expect: 100-continue để làm gì

Theo RFC 9110, giá trị duy nhất được định nghĩa cho Expect là 100-continue. Mục đích là tiết kiệm băng thông: nếu máy chủ sẽ từ chối vì thân quá lớn hay chưa xác thực, client biết ngay sau khi gửi header, không phải đẩy hàng megabyte vô ích.

Luồng bình thường có ba bước. Client gửi header kèm Expect: 100-continue rồi chờ. Máy chủ trả HTTP/1.1 100 Continue. Client gửi thân, máy chủ trả mã cuối như 200.

417 xảy ra khi nào

Tài liệu MDN về 417 ghi mã này báo kỳ vọng trong header Expect không đáp ứng được. Có hai trường hợp hay gặp. Thứ nhất, header Expect chứa giá trị lạ, không phải 100-continue. Thứ hai, một hop ở giữa, thường là proxy cũ hoặc thiết bị bảo mật, không hiểu hoặc không muốn xử lý Expect và trả 417 thay vì chuyển tiếp.

Trường hợp thứ hai là thứ người dùng proxy hay gặp. Request đi thẳng thì chạy, đi qua proxy thì 417. Máy chủ đích không có lỗi gì.

Thời gian chờ 100 Continue

Client gửi Expect không chờ mãi. Nếu sau một khoảng ngắn chưa nhận được 100 hay mã cuối, client gửi thân luôn. Chuẩn cho phép hành vi này, vì máy chủ cũ có thể không biết gửi 100. curl mặc định chờ một giây, và lab đo được đúng con số đó ở ca 10.

Thời gian chờ này là thứ biến lỗi giao thức thành lỗi hiệu năng. Request vẫn thành công, chỉ chậm. Không có mã lỗi nào để theo dõi, chỉ có thời gian xử lý tăng đều. Đây là lý do nên theo dõi thời gian upload theo từng đường đi, không chỉ tỷ lệ lỗi.

100 Continue không phải lỗi

Mã 100 là phản hồi tạm, không phải mã cuối. Nhiều công cụ ghi log hiện cả dòng HTTP/1.1 100 Continue rồi mới tới HTTP/1.1 200 OK. Người đọc log lần đầu dễ tưởng có hai request hoặc có lỗi. Thật ra đó là một request với một phản hồi tạm và một phản hồi cuối.

417 là mã cuối báo kỳ vọng thất bại, còn 100 là phản hồi tạm báo kỳ vọng được chấp nhận; hai mã này ngược nghĩa nhau.

Upload qua proxy hay gặp ở đâu

Người dùng proxy upload nhiều hơn họ nghĩ. Đăng ảnh sản phẩm lên sàn, đăng video, gửi tệp qua API, đẩy dữ liệu crawl về máy chủ trung tâm, gửi biểu mẫu có tệp đính kèm. Mỗi việc này là một request POST hoặc PUT có thân lớn, đúng loại request mà client hay gắn Expect.

Với công cụ dòng lệnh và script tự viết, curl là client phổ biến nhất, nên phần lớn lỗi 417 qua proxy xuất hiện ở các script dùng curl hay thư viện dựa trên libcurl như PHP cURL. Bài PHP cURL proxy có cách đặt proxy cho thư viện này.

Ranh giới với các bài đã có

Bài lỗi 408 Request Timeout nói về máy chủ chờ request quá lâu. Bài lỗi 400 Bad Request nói về request sai cú pháp. Bài này chỉ đi vào Expect, 100 Continue và 417, xác định hop nào gây lỗi khi upload qua proxy.

Đọc Expect: 100-continue qua các hop và xác định bên từ chối kỳ vọng khi gặp lỗi 417 Expectation Failed

Mỗi hop trên đường đi có thể xử lý Expect theo cách riêng. Phần này đi qua ba cách xử lý và hệ quả của từng cách.

Cách một: chuyển tiếp Expect

Proxy hiểu HTTP/1.1 đầy đủ sẽ chuyển tiếp header Expect tới máy chủ đích, rồi chuyển phản hồi 100 Continue ngược về client. Client nhận 100, gửi thân, proxy chuyển thân đi. Mọi thứ diễn ra như không có proxy.

Proxy cũng có thể tự trả 100 Continue cho client trước khi hỏi máy chủ đích, nếu nó sẵn sàng nhận và lưu tạm thân. Cách này hợp lệ nhưng làm mất lợi ích tiết kiệm băng thông ở chặng sau.

Cách hai: từ chối Expect bằng 417

Proxy cũ hoặc cấu hình chặt có thể trả 417 ngay khi thấy header Expect. Lý do thường là proxy chỉ hỗ trợ HTTP/1.0 ở phía sau, không bảo đảm chuyển được phản hồi 100. Trả 417 là cách an toàn với proxy nhưng làm hỏng mọi upload có Expect.

Phản hồi 417 này đến từ proxy, máy chủ đích không hề thấy request. Header phản hồi thường mang dấu vết của proxy, như tên phần mềm trong header Server hoặc Via. Bài Via header giải thích cách đọc dấu vết hop.

Cách ba: xóa Expect rồi chuyển tiếp

Ba cách xử lý Expect

Proxy có thể xóa header Expect và chuyển request đi như request thường. Máy chủ đích không biết client đang chờ, nên không gửi 100 Continue. Client chờ phản hồi 100 không bao giờ tới.

Client tốt có thời gian chờ cho 100 Continue. Hết thời gian, nó gửi thân luôn. Request vẫn thành công, nhưng mỗi upload chậm thêm đúng bằng thời gian chờ. Đây là lỗi không hiện thành mã lỗi, chỉ hiện thành độ trễ.

Expect với giá trị lạ

Chuẩn chỉ định nghĩa 100-continue. Mọi giá trị khác đều là kỳ vọng máy chủ không hiểu và phải trả 417. Giá trị lạ thường do mã tự viết đặt sai, hoặc do công cụ gửi header thừa. Ca 5 của lab gửi Expect: something-else và nhận 417 ngay từ máy chủ đích.

Khi thấy 417 mà không có proxy ở giữa, kiểm giá trị Expect trước tiên. Lỗi gõ như 100-Continue với khoảng trắng thừa hay kèm tham số cũng có thể bị một số máy chủ coi là giá trị lạ.

Ai gửi Expect

Không phải client nào cũng gửi Expect. curl gửi tự động khi thân POST hoặc PUT vượt một ngưỡng kích thước. Thư viện requests của Python không gửi. HttpClient của .NET từng bật mặc định trên .NET Framework. Ứng dụng tự viết có thể gửi tay.

Vì vậy cùng một proxy, upload bằng curl gặp 417, upload bằng Python thì không. Khác biệt nằm ở client, không phải ở dữ liệu.

Thiết kế lab lỗi 417 Expectation Failed: phiên bản và phép đo

Lab chạy ngày 29/10/2026 trên Windows 10. Mọi thành phần viết bằng Python 3.12.10 dùng socket, không dùng thư viện máy chủ có sẵn, để kiểm soát từng byte. Client là curl 8.13.0 bản đi kèm Windows và requests 2.34.2.

Máy chủ đích

Máy chủ đích ở 127.0.0.1 cổng 9541. Nếu request có Expect khác 100-continue, máy chủ trả 417. Nếu có Expect: 100-continue và Content-Length trên 4 MiB, máy chủ trả 413 ngay, không đọc thân. Nếu có Expect: 100-continue và thân hợp lệ, máy chủ gửi 100 Continue, đọc thân rồi trả 200 kèm số byte đã nhận.

Ba proxy

Proxy A ở cổng 9542 chuyển tiếp nguyên header, kể cả Expect, và chuyển phản hồi hai chiều. Proxy B ở cổng 9543 mô phỏng hop cũ: thấy Expect là trả 417 ngay. Proxy C ở cổng 9544 xóa header Expect rồi chuyển tiếp.

Mỗi hop ghi log dòng request và header Expect nó thấy. Phản hồi do proxy tự tạo mang header X-Hop với tên proxy, phản hồi từ máy chủ đích mang X-Hop: origin.

Ghi log ở mỗi hop

Mỗi proxy ghi dòng request đầu và giá trị Expect nó nhận được. Máy chủ đích ghi thêm Content-Length, header Via và mỗi lần gửi 100 Continue hay trả lỗi sớm. Đọc log ba nơi theo thời gian cho biết request dừng ở đâu và header nào bị thay đổi trên đường.

Cách log theo hop này cũng là cách nên làm khi tự vận hành nhiều tầng proxy thật. Thiếu log ở một tầng là thiếu một mảnh để biết lỗi xuất phát từ đâu.

Ba cỡ thân

Thân 2 KB đại diện form nhỏ. Thân 2 MB đại diện tệp ảnh. Thân 5 MB vượt giới hạn 4 MiB của máy chủ đích. Dữ liệu là byte ngẫu nhiên tạo lúc chạy, xóa sau khi chạy.

Vì sao tự viết proxy thay vì dùng phần mềm có sẵn

Phần mềm proxy thật như Squid hay Nginx đều xử lý Expect đúng chuẩn ở bản hiện tại. Muốn thấy ba cách xử lý khác nhau trong cùng một lab, cách đơn giản nhất là viết ba proxy nhỏ, mỗi cái làm đúng một hành vi. Mỗi proxy chỉ vài chục dòng Python dùng socket.

Nhờ tự viết, lab biết chắc hop nào làm gì và log được mọi header. Kết quả vì vậy dùng để hiểu cơ chế, không dùng để kết luận về một phần mềm proxy cụ thể nào.

Phép đo

Với mỗi ca, curl ghi mã trạng thái, thời điểm nhận byte phản hồi đầu, tổng thời gian và số byte đã upload. Log chi tiết của curl cho biết nó có gửi Expect và có nhận 100 Continue hay không.

Tái lập lỗi 417 Expectation Failed: luồng đúng và các ca lỗi có kiểm soát

Phần này đưa bảng kết quả thật và giải thích từng dòng.

Lệnh curl

curl -s -o NUL -w "%{http_code} %{time_starttransfer} %{time_total} %{size_upload}" -v --data-binary @b2m.bin http://127.0.0.1:9541/up
curl -x http://127.0.0.1:9543 --data-binary @b2m.bin http://127.0.0.1:9541/up
curl -x http://127.0.0.1:9543 --data-binary @b2m.bin -H "Expect:" http://127.0.0.1:9541/up

Dòng cuối dùng -H "Expect:" với giá trị rỗng, cách trang man curl hướng dẫn để bỏ một header curl tự thêm.

Bảng kết quả

Upload 0 byte và 1 giây

Bảng: Bảng kết quả

Ca	Đường đi	Cỡ thân	curl gửi Expect	Nhận 100	Mã	Byte đã upload	Tổng thời gian
1	Thẳng	2 KB	Không	Không	200	2.048	0,001 giây
2	Thẳng	2 MB	Có	Có	200	2.097.152	0,010 giây
3	Thẳng	5 MB	Có	Không	413	0	0,001 giây
4	Thẳng, tắt Expect	5 MB	Không	Không	200	5.242.880	0,047 giây
5	Thẳng, Expect lạ	2 KB	Có	Không	417	2.048	0,001 giây
6	Qua A	2 MB	Có	Có	200	2.097.152	0,016 giây
7	Qua B	2 MB	Có	Không	417	0	0,001 giây
8	Qua B, tắt Expect	2 MB	Không	Không	200	2.097.152	0,035 giây
9	Qua B	2 KB	Không	Không	200	2.048	0,002 giây
10	Qua C	2 MB	Có	Không	200	2.097.152	1,011 giây
11	requests thẳng	2 MB	Không	Không	200	2.097.152	Không đo

curl 8.13 gửi Expect theo cỡ thân

Ca 1 với 2 KB không có Expect, ca 2 với 2 MB có Expect. Với curl 8.13.0, ngưỡng tự gửi Expect lớn hơn 2 KB và nhỏ hơn hoặc bằng 2 MB. Các bản curl cũ hơn dùng ngưỡng thấp hơn, nên cùng một lệnh trên máy khác có thể gửi Expect cả với thân nhỏ.

Ca 11 cho thấy requests không gửi Expect với 2 MB. Cùng dữ liệu, cùng máy chủ, hai client cho hai hành vi khác nhau.

Lợi ích của Expect: ca 3

Ca 3 gửi 5 MB tới máy chủ giới hạn 4 MiB. Máy chủ trả 413 ngay sau header, curl báo 0 byte đã upload. Thân 5 MB không đi trên dây. So với ca 4 tắt Expect, curl đẩy đủ 5.242.880 byte rồi mới biết kết quả. Máy chủ lab chỉ kiểm giới hạn khi có Expect nên ca 4 ra 200. Máy chủ thật kiểm cả khi không có Expect, và sẽ trả 413 sau khi đã nhận hết 5 MB vô ích.

Ca 7: hop cũ trả 417

Ca 7 qua proxy B với 2 MB nhận 417, 0 byte upload. Log của máy chủ đích không có dòng nào cho ca này, chỉ log proxy B ghi đã thấy Expect: 100-continue. Phản hồi mang X-Hop: proxyB. Đây là mẫu chuẩn của lỗi 417 do hop ở giữa.

Ca 9 cùng proxy B nhưng thân 2 KB thì thành công, vì curl không gửi Expect. Người dùng sẽ thấy upload ảnh nhỏ chạy, upload tệp lớn lỗi, và dễ nghĩ sai là lỗi kích thước.

Ca 8 tắt Expect bằng -H "Expect:" thì qua B thành công. curl 8.13 không tự thử lại khi nhận 417 trong lab này, người dùng phải tắt Expect.

Ca 6: hop chuyển tiếp đúng

Ca 6 qua proxy A với 2 MB có Expect, nhận 100 Continue và 200. Máy chủ đích ghi header Via: 1.1 proxyA, chứng tỏ request đã qua proxy, và Expect còn nguyên. Thời gian 0,016 giây, chỉ nhỉnh hơn đi thẳng một chút vì thêm một hop.

Đây là hành vi mong muốn của mọi proxy HTTP/1.1. Nếu proxy của anh em cho kết quả như ca 6, Expect không phải nguyên nhân của bất kỳ lỗi upload nào đang gặp.

Ca 10: hop xóa Expect, mất một giây

Ca 10 qua proxy C thành công nhưng tổng thời gian 1,011 giây, so với 0,016 giây qua A. curl gửi header kèm Expect, proxy C xóa Expect, máy chủ đích không gửi 100. curl chờ hết thời gian chờ mặc định cho 100 Continue rồi gửi thân.

Hop xóa Expect không gây lỗi, nó làm mỗi upload lớn chậm thêm đúng thời gian chờ của client. Với crawler hay công cụ đồng bộ upload hàng nghìn tệp, một giây mỗi tệp là rất lớn.

Đọc log, gói tin và response để tách lỗi 417 Expectation Failed với lỗi gần giống

Phần này giúp xác định nhanh hop nào trả 417 và phân biệt với các lỗi upload khác.

Đọc log chi tiết của curl

Với -v, curl in dòng có dấu lớn hơn cho header gửi đi và dấu nhỏ hơn cho header nhận về. Tìm dòng Expect: 100-continue ở phần gửi. Nếu ngay sau đó là HTTP/1.1 417, hop gần nhất đã từ chối. Nếu là HTTP/1.1 100 Continue, kỳ vọng được chấp nhận ở đâu đó.

curl còn in thông báo khi hết thời gian chờ 100 và gửi thân luôn. Thấy thông báo này lặp lại mỗi upload là dấu hiệu của ca 10: có hop xóa Expect.

Xác định hop trả 417

Tìm hop trả 417

Bảng: Xác định hop trả 417

Dấu hiệu	Do máy chủ đích	Do proxy
Log máy chủ đích	Có dòng request	Không có
Header Server hoặc X-Hop	Của máy chủ đích	Của proxy
Đi thẳng không qua proxy	Vẫn 417	Hết 417
Tắt Expect	Có thể hết nếu Expect lạ	Hết 417

Cách nhanh nhất là chạy lại đúng lệnh không qua proxy. Nếu hết lỗi, proxy là thủ phạm. Nếu vẫn lỗi, xem giá trị Expect có phải 100-continue không, giá trị lạ sẽ bị máy chủ đích từ chối như ca 5.

Đo trên nhiều lần chạy

Ca hop xóa Expect chỉ lộ ra khi đo thời gian. Chạy cùng lệnh upload ba lần qua proxy và ba lần đi thẳng, so tổng thời gian. Nếu qua proxy luôn chậm hơn khoảng một giây bất kể cỡ thân, gần như chắc có hop xóa Expect. Nếu chênh lệch tăng theo cỡ thân, đó là băng thông của proxy, không phải Expect.

Bảng phân biệt với lỗi upload khác

Bảng: Bảng phân biệt với lỗi upload khác

Mã	Ý nghĩa	Khi nào gặp khi upload	Bài liên quan
417	Kỳ vọng thất bại	Có Expect, hop không xử lý	Bài này
413	Thân quá lớn	Vượt giới hạn máy chủ hoặc proxy	Giới hạn kích thước
411	Thiếu Content-Length	Máy chủ đòi độ dài	Lỗi độ dài
408	Hết thời gian chờ request	Gửi thân quá chậm	[lỗi 408](https://proxy.vn/blogs/loi-408-request-timeout)
415	Kiểu dữ liệu không hỗ trợ	Content-Type sai	[lỗi 415](https://proxy.vn/blogs/loi-415-unsupported-media-type)
407	Proxy cần xác thực	Thiếu thông tin proxy	[lỗi 407](https://proxy.vn/blogs/sua-loi-407-proxy-authentication-required)

413 và 417 hay đi cùng nhau vì đều xuất hiện khi upload lớn. Phân biệt bằng mã, đừng gộp chung thành "lỗi upload".

Đọc log phía máy chủ đích

Nếu có quyền xem log máy chủ đích, tìm request upload theo thời điểm. Có dòng request kèm mã 417 nghĩa là máy chủ đích từ chối, thường vì giá trị Expect lạ. Không có dòng nào nghĩa là request dừng ở hop trước. Có dòng request với mã 200 nhưng thời gian xử lý dài bất thường gợi ý ca hop xóa Expect.

Một số máy chủ ghi riêng việc gửi 100 Continue. Nếu log ghi đã gửi 100 mà client vẫn chờ hết thời gian, phản hồi 100 bị mất ở hop giữa, cũng là dạng hop không chuyển tiếp đúng.

Gói tin cho thấy gì

Trên dây, ca 7 chỉ có header request đi và phản hồi 417 về, không có thân. Ca 10 có header đi, khoảng lặng một giây, rồi thân đi. Bắt gói hoặc xem thời gian time_starttransfer của curl đều thấy khoảng lặng này.

Xử lý lỗi 417 Expectation Failed theo bằng chứng và checklist

Checklist lỗi 417

Cách xử lý tùy hop gây lỗi và tùy quyền của anh em với hop đó.

Phía client: tắt Expect khi đi qua hop cũ

Với curl, thêm -H "Expect:" vào lệnh. Với thư viện dùng libcurl, đặt header Expect rỗng. Với .NET, tắt tùy chọn Expect100Continue. Cách này sửa cả ca 417 và ca chậm một giây.

Đánh đổi là mất lợi ích kiểm sớm như ca 3. Nếu thường upload tệp có thể bị từ chối, tốt hơn là kiểm điều kiện trước bằng request nhỏ, như HEAD hay một API kiểm quota, rồi mới upload.

Phía client: giảm thời gian chờ 100

curl có tùy chọn --expect100-timeout đặt thời gian chờ 100 Continue tính bằng giây. Đặt 0,2 giây giảm thời gian mất khi gặp hop xóa Expect từ một giây xuống 0,2 giây, mà vẫn giữ Expect với hop chuyển tiếp đúng. Lab chạy ca thẳng 2 MB với --expect100-timeout 0.2 nhận 100 bình thường và 200 trong 0,009 giây.

Phía client: thư viện khác

PHP cURL đặt header Expect rỗng bằng tùy chọn CURLOPT_HTTPHEADER với chuỗi Expect và dấu hai chấm. Thư viện Java như Apache HttpClient có tùy chọn bật hoặc tắt expect-continue trong cấu hình request. Node.js không tự gửi Expect, chỉ gửi khi mã đặt tay.

Với mỗi thư viện, cách kiểm nhanh là gửi một upload lớn tới một máy chủ ghi header, như máy chủ đích của lab, rồi xem có header Expect không. Biết client có gửi hay không giúp khoanh vùng ngay khi gặp 417.

Phía proxy tự quản

Nếu tự vận hành proxy, cấu hình để chuyển tiếp Expect đúng chuẩn. Proxy hiện đại như Squid bản mới, HAProxy, Nginx đều xử lý được 100-continue. Hop trả 417 thường là phiên bản cũ hoặc thiết bị bảo mật cấu hình chặt, nâng cấp hoặc đổi cấu hình là cách sửa gốc.

Phía proxy tự quản: kiểm sau khi nâng cấp

Sau khi đổi cấu hình hay nâng cấp proxy, chạy lại bộ ca của lab: upload 2 KB và 2 MB bằng curl qua proxy, xem có Expect, có 100, mã cuối và thời gian. Kết quả như ca 6 là đạt. Lưu bộ lệnh này làm phép thử sau mỗi lần thay đổi.

Phía proxy thương mại

Với proxy mua ngoài, anh em không sửa được hop. Gửi cho nhà cung cấp bằng chứng: lệnh curl có -v, dòng Expect gửi đi và dòng 417 nhận về kèm header Server. Trong lúc chờ, tắt Expect ở client.

Upload qua proxy cho crawler

Crawler thường tải về nhiều hơn tải lên, nhưng bước đẩy kết quả về kho lưu trữ hay gọi API ghi dữ liệu là upload. Nếu bước này đi qua cùng proxy với bước tải trang, lỗi 417 có thể làm mất dữ liệu đã thu. Tách đường đi: tải trang qua proxy, đẩy kết quả về kho nội bộ không qua proxy, đặt địa chỉ kho trong NO_PROXY.

Bài no_proxy là gì có cách đặt. Cách này vừa tránh 417, vừa tiết kiệm băng thông proxy cho đúng việc cần IP khác.

Ghi kết quả kiểm vào tài liệu vận hành

Khi đã xác định proxy nào xử lý Expect sai, ghi lại vào tài liệu nội bộ: proxy nào, cách xử lý nào, đã tắt Expect ở client nào. Người sau gặp 417 hay upload chậm một giây sẽ biết ngay nguyên nhân thay vì dò lại từ đầu. Ghi kèm phiên bản curl, vì ngưỡng tự gửi Expect thay đổi theo phiên bản.

Giới hạn suy luận của bài

Ba proxy trong lab là mô phỏng tự viết, mỗi cái thể hiện một cách xử lý Expect. Lab chưa thử Squid, Nginx, HAProxy hay thiết bị bảo mật thật. Ngưỡng tự gửi Expect của curl ghi theo bản 8.13.0 trên Windows, bản khác có thể khác. Hành vi .NET ghi theo tài liệu, chưa chạy.

Máy chủ đích lab có giới hạn 4 MiB và trả 413 trước khi đọc thân. Máy chủ thật có thể đọc một phần thân trước khi trả lỗi.

Checklist lỗi 417 Expectation Failed

• Chạy lại với -v, tìm dòng Expect gửi đi và mã nhận về.
• Chạy lại không qua proxy để biết hop nào trả 417.
• Kiểm giá trị Expect có phải 100-continue không.
• So upload thân nhỏ và thân lớn, vì client chỉ gửi Expect với thân lớn.
• Tắt Expect bằng -H "Expect:" khi đi qua hop cũ.
• Đặt --expect100-timeout ngắn nếu upload chậm đều một giây.
• Báo nhà cung cấp proxy kèm log curl nếu hop là proxy thuê.
• Phân biệt 417 với 413, 411, 408 trước khi sửa.

Với upload qua proxy, nên chọn proxy hỗ trợ HTTP/1.1 đầy đủ để Expect đi thông. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay qua HTTP hoặc SOCKS5. Anh em có thể mua proxy uy tín tại trang chủ ProxyVN rồi chạy lại bộ lệnh curl ở trên để kiểm từng ca.

Câu hỏi thường gặp về lỗi 417 Expectation Failed

Proxy SOCKS5 có gây 417 không?

Không. SOCKS5 chuyển tiếp byte TCP, không đọc header HTTP. Expect đi thẳng tới máy chủ đích. Nếu gặp 417 qua SOCKS5, lỗi nằm ở máy chủ đích hoặc giá trị Expect.

HTTPS qua proxy có gặp 417 do proxy không?

Thường không. Với HTTPS, proxy chỉ mở đường hầm CONNECT, header Expect nằm trong phần mã hóa. Proxy không đọc được nên không từ chối được. Lỗi 417 do proxy chủ yếu xảy ra với HTTP thường.

Lỗi 417 có làm mất dữ liệu đã gửi không?

Không, vì thân chưa được gửi. Client nhận 417 trước khi đẩy thân, như ca 7 với 0 byte upload. Chỉ cần gửi lại request không có Expect.

HTTP/2 có Expect không?

Có, HTTP/2 vẫn dùng Expect: 100-continue. Hành vi giống nhau về ý nghĩa, khác về cách đóng khung dữ liệu.

Proxy xoay có ảnh hưởng tới Expect không?

Không trực tiếp. Mỗi kết nối qua proxy xoay có thể ra IP khác, nhưng cách proxy xử lý Expect phụ thuộc phần mềm proxy, không phụ thuộc IP thoát. Nếu cổng xoay dùng chung một phần mềm, kết quả giống nhau ở mọi lần.

Vì sao Python không gặp lỗi mà curl gặp?

requests không gửi Expect. curl gửi khi thân lớn. Khác client, khác hành vi.

Trình duyệt có gửi Expect không?

Trình duyệt thường không gửi Expect khi gửi biểu mẫu hay gọi fetch. Lỗi 417 qua proxy vì vậy hiếm gặp trên trình duyệt, chủ yếu gặp ở công cụ dòng lệnh, script và ứng dụng máy tính.

Có nên luôn tắt Expect?

Không cần. Chỉ tắt khi có hop xử lý sai. Với đường đi tốt, Expect giúp tránh upload thừa khi máy chủ từ chối.

Lỗi 417 Expectation Failed và những điều cần nhớ

Lỗi 417 Expectation Failed thường do một hop ở giữa không xử lý Expect: 100-continue, không phải do máy chủ đích. Lab cho thấy curl 8.13 chỉ gửi Expect với thân lớn, hop cũ trả 417 với 0 byte upload, hop xóa Expect làm upload chậm thêm đúng một giây. Đọc log -v, thử không proxy, tắt Expect hoặc rút thời gian chờ. Cần proxy chuyển tiếp HTTP/1.1 đúng chuẩn khi xử lý lỗi 417 Expectation Failed, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.