Паузе при 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-а; посредник за прослеђивање не прегледа једноставно унутрашње заглавље очекивања. Пут пресретања или прослеђивања чистим текстом је другачији.
Уклањање очекивања може бити свестан избор компатибилности, али значи да клијент може почети да шаље велико тело пре него што сазна за рано одбијање. Упоредите то понашање са стварним захтевом. Не описујте историјско решење за стари посредник као универзалну упутство за уклањање заглавља из сваког отпремања.