1xx: informationale Statuscodes

Was eine Zwischenantwort ist

Jede andere Statusfamilie beendet den Austausch. Ein 200, ein 404 oder ein 502 ist das letzte Wort des Servers zu dieser Anfrage. Ein 1xx ist anders: Der Server sendet die Statuszeile und etwaige Header, hält die Verbindung dann offen und sendet später eine zweite Antwort. RFC 9110 verlangt, dass Clients in der Lage sein müssen, eine oder mehrere 1xx-Antworten vor der endgültigen zu lesen, und erlaubt jedem Client, der einen bestimmten 1xx-Code nicht kennt, ihn zu ignorieren.

Die Zwischenantwort wird verworfen, sobald die endgültige eintrifft, die meisten Tools zeigen sie daher nie an. Das Netzwerk-Panel Ihres Browsers, das Zugriffsprotokoll Ihres Webservers und eine Monitoring-Prüfung melden allesamt den endgültigen Status. Die Zwischenantwort hat ihre Aufgabe auf Transportebene erledigt und ist wieder verschwunden.

Die 1xx-Codes, auf die Sie stoßen könnten

• 100 Continue. Der Client hat Anfrage-Header mit Expect: 100-continue gesendet und wartet, bevor er einen großen Body sendet. Ein 100 bedeutet "Header sehen gut aus, sende den Body". Würde der Server die Anfrage ohnehin ablehnen, kann er stattdessen direkt mit einem endgültigen Fehler antworten, und der Client verschwendet keine Bandbreite mit dem Hochladen der Nutzlast. Das ist der einzige 1xx-Code, der auf gewöhnlichen Websites nützliche Arbeit leistet, meist bei großen Datei-Uploads und API-Clients wie curl.
• 101 Switching Protocols. Der Client hat mit einem Upgrade-Header um einen Protokollwechsel gebeten, und der Server hat zugestimmt. Das ist das normale, erfolgreiche Ergebnis eines WebSocket-Handshakes, ein 101 im Protokoll ist also im Allgemeinen ein gutes Zeichen, kein Vorfall.
• 102 Processing. Von der WebDAV-Spezifikation für lange laufende Anfragen definiert, damit der Client weiß, dass der Server nicht hängengeblieben ist. Es wird außerhalb von WebDAV selten implementiert, und Sie werden ihm auf einer normalen Website kaum begegnen.
• 103 Early Hints. Der Server sendet Link-Header früh, bevor er die Seite fertig generiert hat, damit der Browser bereits beginnen kann, Stylesheets, Schriftarten oder Skripte vorzuladen, während das HTML noch erzeugt wird. Das ist eine Leistungsfunktion, kein Fehlersignal, und Sie schalten sie normalerweise bewusst am CDN oder am Ursprungsserver ein.

Warum ein 1xx nichts ist, das man beheben muss

Ein 1xx allein trägt keinen Fehler in sich. Es gibt so etwas wie eine Seite, die "100 zurückgibt" oder "101 zurückgibt", nicht in dem Sinn, wie eine Seite 404 zurückgeben kann. Haben Sie ein Problem und ein 1xx steckt irgendwo im Austausch, ist die interessante Information immer der endgültige Statuscode, der darauf folgte, oder die Tatsache, dass überhaupt keine endgültige Antwort eintraf.

Die echten Fehlerarten rund um 1xx zeigen sich als Hänger oder als endgültiger Fehler, nicht als das 1xx selbst:

• Ein alter Proxy oder Load Balancer, der Zwischenantworten nicht weiterleitet, sodass ein auf 100 Continue wartender Client hängt, bis sein eigenes Timeout auslöst.
• Ein WebSocket-Upgrade, das nie ein 101 erreicht, weil ein Proxy vor der Anwendung die Header Upgrade und Connection entfernt. Die Verbindung fällt dann zurück oder schlägt ganz fehl.
• Early Hints, die mit Links zu nicht mehr existierenden Ressourcen ausgeliefert werden, was Anfragen verschwendet, ohne die Seite zu beschädigen.

Wie Sie eine 1xx-Antwort selbst sehen

1. Verwenden Sie einen ausführlichen Client. Ein gewöhnliches curl -I zeigt nur die endgültigen Antwort-Header, fragen Sie also stattdessen nach dem vollständigen Austausch:

   curl -v -H "Expect: 100-continue" --data-binary @big.bin https://example.com/upload

   Ein kooperierender Server antwortet mit HTTP/1.1 100 Continue, bevor der Body hinausgeht, und danach mit dem endgültigen 2xx oder 4xx.
2. Prüfen Sie bei einem WebSocket-Pfad, ob der Handshake HTTP/1.1 101 Switching Protocols erreicht. Wenn nicht, schauen Sie zuerst auf die Proxy-Ebene: Upgrade-Header sind hop-by-hop, und mehrere gängige Reverse-Proxy-Konfigurationen verwerfen sie standardmäßig.
3. Fragen Sie für Early Hints die Seite ab und suchen Sie nach einem 103-Block vor der endgültigen Antwort. Nicht jeder Vermittler leitet ihn weiter, ein fehlendes 103 bedeutet also nicht immer, dass der Ursprung keines sendet.
4. Hängt ein großer Upload ohne jede Antwort, versuchen Sie es erneut ohne den Expect-Header. Gelingt der erneute Versuch, verschluckt etwas zwischen Ihnen und dem Ursprung Zwischenantworten.

Einen Austausch überwachen, den Sie nicht sehen können

Da 1xx-Codes nie in einem Protokoll oder Dashboard ankommen, überwachen Sie die endgültige Antwort und wie lange sie gebraucht hat, um einzutreffen. Ein an einer Zwischenantwort hängender Upload-Pfad sieht von außen exakt wie ein langsamer oder ins Timeout laufender Endpunkt aus, und eine externe Prüfung sieht das sofort. HostTracker führt Prüfungen von über 300 Prüfpunkten in 158 Städten aus, eine Anfrage, die hinter einem bestimmten Netzwerkpfad hängt, lässt sich also von einem echten Ausfall unterscheiden. Führen Sie eine URL durch das HTTP-Prüfungstool, um den endgültigen Status und die Antwortzeit zu sehen. Die Anleitungen zu den 2xx-Erfolgscodes und den 3xx-Weiterleitungscodes behandeln die Antworten, die einen Austausch tatsächlich beenden.