Inhaltslänge wird verwendet, um die Übertragungslänge des Nachrichtenkörpers zu beschreiben. Im HTTP-Protokoll gibt es einen Unterschied zwischen der Länge der Nachrichtenentität und der Übertragungslänge der Nachrichtenentität, zum Beispiel entspricht bei der Gzip-Kompression die Länge der Nachrichtenentität der Länge vor der Kompression und die Übertragungslänge der Nachrichtenentität der Länge nach der Gzip-Kompression.
Bei spezifischen HTTP-Interaktionen basiert die Erlangung der Nachrichtenlänge des Clients hauptsächlich auf den folgenden Regeln:
Wenn die Antwort 1xx, 204, 304 oder eine Kopfanfrage ist, wird der Inhalt der Nachrichtenentität direkt ignoriert.
Wenn es Transfer-Encoding gibt, wird die Methode in Transfer-Encoding bevorzugt, um die entsprechende Länge zu bestimmen. Zum Beispiel das Chunked-Modell.
"Wenn es eine Inhalts-Länge im Kopf gibt, dann repräsentiert diese Inhaltslänge sowohl die Körperlänge als auch die Übertragungslänge. Wenn die Entitätslänge und die Übertragungslänge nicht gleich sind (z. B. wird Transfer-Encoding gesetzt), kann die Inhaltslänge nicht gesetzt werden.Wenn Transfer-Encoding gesetzt ist, wird Content-Length ignoriert”。 Der Vorteil dieser Satzübersetzung ist, dass es nur einen Punkt gibt: Bei Transfer-Encoding kann es keine Inhaltslänge geben.
Reichweitenübertragung. Ich habe nicht aufgepasst, ich habe es nicht im Detail gelesen :)
Das Schließen der Verbindung über den Server bestimmt die Länge der gesendeten Nachricht. (Der Anforderer kann das Ende des Anfragekörpers nicht durch das Schließen der Verbindung anzeigen, da der Server sonst keine Chance mehr hätte, weiter zu antworten.) Diese Situation entspricht hauptsächlich kurzen Verbindungen, also dem Nicht-Leben-Halt-Modus.
HTTP 1.1 muss den Chunk-Modus unterstützen. Denn wenn die Länge der Nachricht unsicher ist, kann diese Situation über den Chunk-Mechanismus gehandhabt werden.
Im Header, der den Nachrichteninhalt enthält, muss der entsprechende Wert des Feldes, falls es ein Inhaltslängenfeld gibt, genau der Länge des Nachrichtenthemas entsprechen.
"Die Entitätslänge einer Nachricht ist die Länge des Nachrichtenkörpers, bevor alle Transfercodierungen angewendet wurden"
Das heißtWenn es einen Chunk gibt, kann es keine Inhaltslänge geben 。
Der persistente Verbindungsmechanismus von HTTP/1.0 wurde später eingeführt und wird über den Header Connection: keep-alive implementiert, der sowohl vom Server als auch vom Client genutzt werden kann, um sich gegenseitig mitzuteilen, dass sie nach dem Senden der Daten die TCP-Verbindung nicht abbrechen müssen.HTTP/1.1 verlangt, dass alle Verbindungen persistent sind，Außer du fügst explizit Connection hinzu: in der Nähe des Headers。 Tatsächlich hat das Connection-Headerfeld in HTTP/1.1 nicht mehr den Wert von Keep-alive, aber aus historischen Gründen behalten viele Webserver und Browser weiterhin die Gewohnheit, Connection: Keep-alive zu HTTP/1.1-langen Verbindungen zu senden.
Tatsächlich lassen sich die letzten fast ignorieren, und eine kurze Zusammenfassung lautet wie folgt:
1. Inhalt-Länge: Wenn sie existiert und gültig ist, muss sie genau der Übertragungslänge des Nachrichteninhalts entsprechen. (Getestet, um zu kürzen, wenn es zu kurz ist, und zu lang, um eine Auszeit zu verursachen.) ）
2. Wenn es Transfer-Encoding gibt (der Fokus ist gehackt), kann es keine Inhaltslänge im Header geben, und diese wird ignoriert.
3. Wird eine kurze Verbindung verwendet, kann die Übertragungslänge der Nachricht direkt durch Schließen der Verbindung über den Server bestimmt werden. (Das ist leicht zu verstehen)
In Kombination mit anderen Funktionen des HTTP-Protokolls unterstützte Http1.1 beispielsweise kein Keep-Life. Dann lassen sich folgende Schlussfolgerungen ziehen:
1. In Http 1.0 und früheren Versionen ist das Feld zur Inhaltslänge optional.
2. In http1.1 und neueren Versionen. Wenn du am Leben bleibst, müssen Inhaltslänge und Chunk eines von beiden sein. Wenn es nicht lebendig gehalten wird, ist es dasselbe wie http1.0. Inhaltslänge.
|
Veröffentlicht am 24.09.2019 15:53:29
|
|
|
