Premori pri nalaganju HTTP in Expect: 100-continue
Prepoznajte izmenjavo Expect: 100-continue in ločite njeno kratko odločitveno točko od nalaganja, ki se je zataknilo med prenosom podatkov.
Povezava se odpre. Glave zahteve odidejo. Zdi se, da se datoteka ne premika. Ena razlaga je, da odjemalec čaka na odgovor na Expect: 100-continue, preden pošlje telo.
Mehanizem prejemniku omogoča, da zahtevo zavrne na podlagi njenih glav, preden se pošlje morebiti veliko nalaganje. Običajno uspešno zaporedje je:
request headers → 100 Continue → request body → final response100 je informativen: odjemalcu omogoča nadaljevanje, ne pomeni pa, da je bila datoteka shranjena ali da je bila operacija aplikacije uspešna. Git push, ki vrne HTTP 417, je en konkreten primer neizpolnjenega pričakovanja.
Ugotovite, kateri odgovor je prejel odjemalec
| Opazovanje | Kaj raziskati |
|---|---|
| 100 Continue | Odjemalec lahko nadaljuje s telesom |
| Končna zavrnitev pred telesom | Operacija je bila zavrnjena v fazi glav |
| Ni pričakovanega vmesnega odgovora | Politika čakanja odjemalca in obravnava na tej poti |
curl ponuja ločeno nastavitev čakanja expect-continue. Če to čakanje libcurl poteče brez pričakovanega odgovora, telo vseeno pošlje; potek samo po sebi ni neuspešen celoten prenos. Nastavitev je ločena od časa, dovoljenega za celoten prenos. Povečanje slednjega lahko pusti isti začetni premor nerazložen.
Ugotovite tudi, kateri pogovor HTTP prenaša Expect. Pri običajnem CONNECT do cilja HTTPS je izmenjava nalaganja spletnega mesta znotraj TLS; posrednik za posredovanje ne preprosto pregleda notranje glave pričakovanja. Pot prestrezanja ali posredovanja v čistem besedilu je drugačna.
Odstranitev pričakovanja je lahko zavestna izbira združljivosti, vendar pomeni, da lahko odjemalec začne pošiljati veliko telo, preden izve za zgodnjo zavrnitev. To vedenje primerjajte z dejansko zahtevo. Zgodovinske rešitve za star posrednik ne opisujte kot univerzalnega navodila za odstranitev glave iz vsakega nalaganja.