Връзката се отваря. Заглавките на заявката тръгват. Изглежда, че файлът не се движи. Едно обяснение е, че клиентът чака отговор на Expect: 100-continue, преди да изпрати тялото си.

Механизмът позволява на получателя да отхвърли заявка по заглавките ѝ, преди да бъде изпратено потенциално голямо качване. Обичайната успешна последователност е:

request headers → 100 Continue → request body → final response

100 е информационен: позволява на клиента да продължи, но не означава, че файлът е запазен или че операцията на приложението е успяла. Git push, който връща HTTP 417, е един конкретен случай на неуспешно очакване.

Определете кой отговор е получил клиентът

НаблюдениеЗначение за проверка
100 ContinueКлиентът може да продължи с тялото
Окончателен отказ преди тялотоОперацията е отказана на етапа на заглавките
Няма очакван междинен отговорПолитиката на изчакване на клиента и обработката по този път

curl предлага отделна настройка за изчакване на expect-continue. Ако това изчакване на libcurl изтече без очаквания отговор, той изпраща тялото въпреки това; изтичането не е автоматично провал на целия пренос. Настройката е отделна от времето, разрешено за пълния пренос. Увеличаването на последното може да остави същата начална пауза без обяснение.

Определете също кой HTTP разговор носи Expect. При обикновен CONNECT към HTTPS дестинация обменът на качване на сайта е вътре в TLS; предният прокси не просто преглежда вътрешната заглавка на очакването. Пътят с прихващане или предаване на открит текст е различен.

Премахването на очакването може да е съзнателен избор за съвместимост, но означава, че клиентът може да започне да изпраща голямо тяло, преди да научи за ранния отказ. Сравнете това поведение с действителното изискване. Не описвайте историческо заобикаляне за стар прокси като универсална инструкция да се премахва заглавката от всяко качване.

Подобни статии