HTTP-Upload-Pausen und Expect: 100-continue
Erkennen Sie den Austausch Expect: 100-continue und unterscheiden Sie seinen kurzen Entscheidungspunkt von einem Upload, der beim Übertragen von Daten stockt.
Die Verbindung wird geöffnet. Die Anfrage-Header gehen hinaus. Die Datei scheint sich nicht zu bewegen. Eine Erklärung ist, dass der Client auf eine Antwort auf Expect: 100-continue wartet, bevor er seinen Body sendet.
Der Mechanismus erlaubt es einem Empfänger, eine Anfrage anhand ihrer Header abzulehnen, bevor ein potenziell großer Upload gesendet wird. Die übliche erfolgreiche Reihenfolge ist:
request headers → 100 Continue → request body → final response100 ist informativ: Sie erlaubt dem Client weiterzumachen, bedeutet aber nicht, dass die Datei gespeichert wurde oder die Anwendungsoperation erfolgreich war. Ein Git-Push, der HTTP 417 zurückgibt, ist ein konkreter Fall einer gescheiterten Erwartung.
Ermitteln Sie, welche Antwort der Client erhalten hat
| Beobachtung | Zu untersuchende Bedeutung |
|---|---|
| 100 Continue | Der Client kann mit dem Body fortfahren |
| Eine endgültige Ablehnung vor dem Body | Die Operation wurde in der Header-Phase abgelehnt |
| Keine erwartete Zwischenantwort | Die Wartestrategie des Clients und die Behandlung auf diesem Pfad |
curl bietet eine eigene Warte-Einstellung für expect-continue. Läuft diese libcurl-Wartezeit ohne die erwartete Antwort ab, sendet es den Body trotzdem; ein Ablauf ist nicht automatisch eine fehlgeschlagene gesamte Übertragung. Die Einstellung ist getrennt von der Zeit, die für die vollständige Übertragung erlaubt ist. Eine Erhöhung der letzteren kann dieselbe anfängliche Pause unerklärt lassen.
Bestimmen Sie außerdem, welche HTTP-Konversation Expect trägt. Bei gewöhnlichem CONNECT zu einem HTTPS-Ziel liegt der Upload-Austausch der Website innerhalb von TLS; der Forward-Proxy prüft nicht einfach dessen inneren Erwartungs-Header. Ein Abfang- oder Klartext-Weiterleitungspfad ist anders.
Das Entfernen der Erwartung kann eine bewusste Kompatibilitätsentscheidung sein, bedeutet aber, dass der Client möglicherweise einen großen Body sendet, bevor er von einer frühen Ablehnung erfährt. Vergleichen Sie dieses Verhalten mit der tatsächlichen Anforderung. Beschreiben Sie einen historischen Workaround für einen alten Proxy nicht als universelle Anweisung, den Header bei jedem Upload zu entfernen.