Прыпынкі HTTP-выгрузкі і Expect: 100-continue
Распазнайце абмен Expect: 100-continue і адрознівайце яго кароткі пункт рашэння ад выгрузкі, якая затамваецца падчас перадачы даных.
Злучэнне адкрываецца. Загалоўкі запыту сыходзяць. Здаецца, што файл не рухаецца. Адно з тлумачэнняў — кліент чакае адказу на Expect: 100-continue, перш чым адправіць цела.
Механізм дазваляе атрымальніку адхіліць запыт па загалоўках, перш чым будзе адпраўлена патэнцыйна вялікая выгрузка. Звычайная паспяховая паслядоўнасць такая:
request headers → 100 Continue → request body → final response100 — інфармацыйны: ён дазваляе кліенту працягваць, але не азначае, што файл захаваны або што аперацыя праграмы ўдалася. Git push, які вяртае HTTP 417, — адзін канкрэтны выпадак няўдалага чакання.
Вызначце, які адказ атрымаў кліент
| Назіранне | Што варта даследаваць |
|---|---|
| 100 Continue | Кліент можа працягваць з целам |
| Канчатковая адмова да цела | Аперацыя адхілена на этапе загалоўкаў |
| Чаканага прамежкавага адказу няма | Палітыка чакання кліента і апрацоўка на гэтым шляху |
curl мае асобную наладку чакання для expect-continue. Калі гэтае чаканне libcurl сканчаецца без чаканага адказу, ён усё роўна адпраўляе цела; заканчэнне не азначае аўтаматычна няўдалую перадачу цалкам. Наладка асобная ад часу, адведзенага на поўную перадачу. Павелічэнне апошняга можа пакінуць тую ж пачатковую паўзу без тлумачэння.
Таксама вызначце, які HTTP-размова нясе Expect. Пры звычайным CONNECT да HTTPS-прызначэння абмен выгрузкі сайта знаходзіцца ўнутры TLS; прамы праксі не проста правярае ягоны ўнутраны загаловак чакання. Шлях перахопу або перадачы адкрытым тэкстам іншы.
Выдаленне чакання можа быць свядомым выбарам сумяшчальнасці, але гэта значыць, што кліент можа пачаць адпраўляць вялікае цела, перш чым даведаецца пра раннюю адмову. Параўнайце такія паводзіны з фактычнай патрабай. Не апісвайце гістарычны абыход для старога праксі як універсальную інструкцыю выдаляць загаловак з кожнай выгрузкі.