Zusammenfassung

  • Expect: 100-continue zeigt an, dass der Client den Inhalt zurückhält, damit Methode, Ziel und Header zuerst eine endgültige Ablehnung auslösen können.
  • 100 ermuntert nur zur Übertragung. Der Ursprung schuldet weiterhin einen Endstatus; auch ein Vermittler kann die vorläufige Erlaubnis erzeugen.
  • Der Client darf das Warten beenden und senden. So wird ein alter Vermittler, der 1xx verschluckt, nicht zur Ursache gegenseitigen Wartens.

Die entscheidbaren Angaben kamen zuerst

Anfragezeile und Header gehen einem optionalen Inhalt voraus. Falsches Ziel, unzulässige Methode oder fehlende Berechtigung können daher erkannt werden, bevor eine große Datei übertragen wird.

Sofortiges Senden verschwendet Kapazität vor 401 oder 405. Pausieren ohne gemeinsames Signal blockiert: Client wartet auf Erlaubnis, Server auf Inhalt. RFC 2068 definierte 1997 den Informationsstatus 100 und musste bereits berücksichtigen, dass HTTP/1.0-Vermittler ihn nicht zuverlässig weitergaben.

Expect machte das Zurückhalten sichtbar

RFC 2616 ergänzte Expect: 100-continue. Der Server konnte nun unterscheiden, ob der Inhalt absichtlich wartet oder schon folgt.

Wer warten will, muss dies anzeigen; ohne Inhalt ist die Erwartung unzulässig. Ist der Inhalt schon teilweise angekommen, darf der Server 100 auslassen. Bei vollständigen HTTP/1.1-Headern, angekündigtem Inhalt und Erwartung sendet der Ursprung sofort einen daraus bestimmbaren Endstatus oder 100, ohne auf den Inhalt zu warten.

Weiter hieß nicht erfolgreich

1xx beendet die Anfrage nicht. Nach 100 muss der Server den Inhalt empfangen, verarbeiten und einen Endstatus senden, sofern die Verbindung nicht vorher endet.

Die Aussage lautet nur: Die bisherigen Angaben rechtfertigen keinen Übertragungsstopp. Authentisierung, Gültigkeit, Speicherung, Ausführung und Erfolg bleiben offen. Deshalb ist 100 weder Transaktionsvorbereitung noch Zweiphasen-Commit; es verwaltet Übertragungskosten.

Der Proxy konnte ermuntern, aber nicht annehmen

Ein Proxy kann einen ihm bekannten Endstatus senden oder Header weiterleiten. Kennt er einen alten nächsten Hop, kann er 100 selbst erzeugen. Das belegt Transportbereitschaft dieses Abschnitts, nicht Sicht oder Annahme des Ursprungs.

417 meldet eine nicht erfüllbare Erwartung. Ein Versuch ohne Expect entfernt die Optimierung, macht die Wiederholung wirkungsvoller Methoden aber nicht automatisch sicher. Entscheidend bleibt, was den Ursprung erreichte.

Schweigen erhielt kein unendliches Vetorecht

RFC 7231 und RFC 9110 schreiben keine feste Wartezeit vor. Der Client darf ohne 100 senden und soll nicht unbegrenzt warten.

Ein alter Hop kann 1xx verlieren. Der lokale Ausstieg tauscht mögliche Byteverschwendung gegen Fortschritt und verhindert Herrschaft durch Schweigen. Eine universelle Größen- oder Latenzschwelle gibt es nicht; kleine Inhalte können durch die zusätzliche Runde sogar verlieren.

Früher Endstatus lässt Framing zurück

Ein Endstatus kann eintreffen, während der Client noch sendet. Der Server schließt oder liest und verwirft den Rest, damit die nächste Nachricht korrekt abgegrenzt bleibt. Anwendungsurteil und Verbindungsbehandlung sind getrennt; Restbytes dürfen auf Wiederverwendung nicht als neue Anfrage erscheinen.

Quellen und Grenzen

Der geschlossene Satz umfasst RFC 2068, RFC 2616, RFC 7231 und RFC 9110. Er belegt Geschichte und Semantik, nicht heutige Verbreitung, Zeitwerte, Byteersparnis oder Vermittlerkonformität.