Pauzy při nahrávání HTTP a Expect: 100-continue
Rozpoznejte výměnu Expect: 100-continue a odlište její krátký rozhodovací bod od nahrávání, které se zaseklo při přenosu dat.
Spojení se otevře. Hlavičky požadavku odcházejí. Zdá se, že se soubor nehýbe. Jedno vysvětlení je, že klient čeká na odpověď na Expect: 100-continue, než odešle tělo.
Mechanismus umožňuje příjemci odmítnout požadavek podle hlaviček dříve, než je odesláno potenciálně velké nahrávání. Obvyklý úspěšný sled je:
request headers → 100 Continue → request body → final response100 je informativní: umožňuje klientovi pokračovat, ale neznamená, že soubor byl uložen nebo že operace aplikace proběhla úspěšně. Git push vracející HTTP 417 je jeden konkrétní případ selhání očekávání.
Zjistěte, kterou odpověď klient dostal
| Pozorování | Význam k prošetření |
|---|---|
| 100 Continue | Klient může pokračovat s tělem |
| Konečné odmítnutí před tělem | Operace byla odmítnuta ve fázi hlaviček |
| Žádná očekávaná přechodná odpověď | Čekací politika klienta a zpracování na této cestě |
curl nabízí samostatné nastavení čekání pro expect-continue. Pokud toto čekání libcurl vyprší bez očekávané odpovědi, tělo přesto odešle; vypršení samo o sobě neznamená selhání celého přenosu. Nastavení je oddělené od času povoleného pro celý přenos. Zvýšení posledního může stejnou počáteční pauzu ponechat nevysvětlenou.
Zjistěte také, která HTTP konverzace nese Expect. Při běžném CONNECT k cíli HTTPS probíhá výměna nahrávání webu uvnitř TLS; dopředná proxy jeho vnitřní hlavičku očekávání jednoduše neprohlíží. Cesta zachycení nebo přenosu v čistém textu je jiná.
Odstranění očekávání může být záměrná volba kompatibility, ale znamená, že klient může začít odesílat velké tělo, než se dozví o raném odmítnutí. Porovnejte toto chování se skutečným požadavkem. Nepopisujte historické obejití pro starou proxy jako univerzální pokyn odstranit hlavičku z každého nahrávání.