HTTP-uploadpauzes en Expect: 100-continue
Herken de Expect: 100-continue-uitwisseling en onderscheid het korte beslismoment ervan van een upload die tijdens het overzetten van gegevens vastliep.
De verbinding gaat open. Requestheaders vertrekken. Het bestand lijkt niet te bewegen. Eén verklaring is dat de client wacht op een reactie op Expect: 100-continue voordat hij de body verstuurt.
Het mechanisme laat een ontvanger een verzoek op basis van de headers weigeren voordat een mogelijk grote upload wordt verzonden. De gebruikelijke succesvolle volgorde is:
request headers → 100 Continue → request body → final response100 is informatief: het laat de client doorgaan, maar betekent niet dat het bestand is opgeslagen of dat de applicatiebewerking is geslaagd. Een Git push die HTTP 417 teruggeeft, is een concreet geval van een mislukte verwachting.
Bepaal welk antwoord de client heeft ontvangen
| Waarneming | Wat te onderzoeken |
|---|---|
| 100 Continue | De client kan met de body doorgaan |
| Een definitieve afwijzing vóór de body | De bewerking werd in de headerfase geweigerd |
| Geen verwacht tussentijds antwoord | Het wachtbeleid van de client en de afhandeling op dat pad |
curl heeft een aparte instelling voor het wachten op expect-continue. Als dat libcurl-wachten verstrijkt zonder het verwachte antwoord, wordt de body alsnog verzonden; het verstrijken is niet automatisch een mislukte hele overdracht. De instelling staat los van de tijd die voor de volledige overdracht is toegestaan. Die laatste verhogen kan dezelfde eerste pauze onverklaard laten.
Stel ook vast welk HTTP-gesprek Expect vervoert. Bij gewone CONNECT naar een HTTPS-bestemming zit de uploaduitwisseling van de website in TLS; de forwardproxy inspecteert de interne verwachtingsheader niet zomaar. Een onderscheppingspad of een pad via platte tekst is anders.
De verwachting verwijderen kan een bewuste compatibiliteitskeuze zijn, maar het betekent dat de client een grote body kan gaan sturen voordat hij van een vroege afwijzing weet. Vergelijk dat gedrag met de werkelijke eis. Beschrijf een historische oplossing voor een oude proxy niet als een universele instructie om de header uit elke upload te verwijderen.