Content-Length

Verwendung

Der Header Content-Length übermittelt die exakte Byte-Größe des HTTP-Nachrichten-Bodys. Clients verlassen sich auf diesen Wert, um zu erkennen, wann eine Antwort vollständig empfangen wurde, wodurch die Verbindung bei persistenten Verbindungen unter HTTP/1.1 zur Wiederverwendung bereitsteht.

Wenn ein Server eine Antwort mit bekannter Body-Größe sendet, ermöglicht der Content-Length-Header dem Client, die passende Menge an Speicher zu reservieren und während des Downloads präzise Fortschrittsanzeigen darzustellen. Eine Abweichung zwischen der angegebenen Länge und der tatsächlichen Body-Größe weist auf eine abgeschnittene oder beschädigte Übertragung hin.

Dieser Header schließt sich gegenseitig mit chunked Transfer-Encoding aus. Wenn ein Server eine Antwort unbekannter Größe streamt, ersetzt die chunked-Kodierung eine feste Inhaltslänge. Unter HTTP/2 und HTTP/3 regelt das Framing die Nachrichtengrenzen auf Protokollebene, Content-Length bleibt jedoch zur Validierung der Body-Größe gültig.

Der Wert ist eine einzelne nicht negative Ganzzahl, die die Anzahl der Oktetts (Bytes) im Nachrichten-Body angibt.

Beispiel

Ein Server gibt eine 3.495 Byte große JSON-Antwort zurück. Der Client liest genau 3.495 Bytes, bevor er die Nachricht als vollständig betrachtet.

Content-Length: 3495

Eine POST-Anfrage sendet einen Formular-Body. Der Content-Length-Header teilt dem Server mit, wie viele Bytes er im Anfrage-Body zu erwarten hat.

POST /submit HTTP/1.1
Host: example.re
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

field=value&other=something

Eine Antwort mit chunked Transfer-Encoding lässt den Content-Length-Header vollständig weg. Der Header Transfer-Encoding hat Vorrang.

Transfer-Encoding: chunked

Fehlersuche

Übertragungsfehler und Verbindungsprobleme lassen sich häufig auf einen falschen oder widersprüchlichen Content-Length-Wert zurückführen.

Übertragung unterbrochen oder Download unvollständig. Der Client empfängt weniger Bytes, als Content-Length angibt, und meldet eine abgeschnittene Antwort. Häufige Ursachen: Der Origin schließt die Verbindung vorzeitig, ein Proxy-Timeout bricht die Übertragung ab, oder der Server berechnet die Body-Größe falsch. Führen Sie curl -v https://example.re/file aus und vergleichen Sie den Wert des Content-Length-Headers mit den tatsächlich empfangenen Bytes (in der Übertragungszusammenfassung angezeigt). Eine Abweichung bestätigt das Problem.

Chunked-Kodierung und Content-Length gleichzeitig vorhanden. Transfer-Encoding: chunked und Content-Length in derselben Antwort zu senden, verstößt gegen die HTTP-Spezifikation. Clients müssen Content-Length ignorieren, wenn Transfer-Encoding vorhanden ist, doch nicht alle Implementierungen halten sich an diese Regel. Entfernen Sie Content-Length, wenn Sie chunked-Kodierung verwenden. In nginx wird die chunked-Kodierung automatisch angewendet, wenn die Body-Größe unbekannt ist, und nginx lässt Content-Length in diesem Fall weg. Eigener Anwendungscode oder Middleware, die beide Header setzt, muss korrigiert werden.

Content-Length falsch, nachdem Middleware den Body verändert hat. Middleware, die Inhalte einfügt (Analyse-Skripte, Sicherheits-Tokens, Debug-Toolbars), verändert die Body-Größe, ohne Content-Length zu aktualisieren. Der Browser schneidet entweder den sichtbaren Inhalt ab oder wartet auf Bytes, die nie eintreffen. Verlagern Sie die Berechnung von Content-Length in die letzte Stufe, nachdem alle Body-Änderungen abgeschlossen sind. In Express.js erledigt die compression-Middleware dies automatisch. In eigenen Konfigurationen entfernen Sie Content-Length und setzen stattdessen auf chunked-Kodierung.

HEAD-Antwort enthält falsche Content-Length. Eine HEAD-Antwort muss dieselbe Content-Length enthalten wie die entsprechende GET-Antwort, jedoch ohne Body. Manche Frameworks erzeugen HEAD-Antworten mit einer Content-Length von 0 oder lassen den Header ganz weg. Überprüfen Sie dies, indem Sie curl -I https://example.re/resource (HEAD) mit curl -s -o /dev/null -w ’%{size_download}’ https://example.re/resource (Body-Größe bei GET) vergleichen. Abweichende Werte beeinträchtigen Download-Manager und Caching-Proxys, die sich auf HEAD verlassen, um die Ressourcengröße zu ermitteln.

Content-Length-Probleme mit curl diagnostizieren. Führen Sie curl -v https://example.re/resource aus, um in der ausführlichen Ausgabe den Content-Length-Header und die übertragene Byte-Anzahl zu sehen. Die Zeile Content-Length: N zeigt die angegebene Größe. Am Ende weist bytes received die tatsächliche Übertragung aus. Ergänzen Sie -o /dev/null, um den Body zu verwerfen und sich auf die Header zu konzentrieren. Denken Sie bei komprimierten Antworten daran, dass Content-Length die komprimierte Größe widerspiegelt, nicht die ursprüngliche Größe.