Content-Length wordt gebruikt om de overdrachtslengte van het berichtlichaam te beschrijven. In het HTTP-protocol is er een verschil tussen de lengte van de berichtentiteit en de transmissielengte van de berichtentiteit, bijvoorbeeld, bij gzip-compressie is de lengte van de berichtentiteit de lengte vóór compressie, en de transmissielengte van de berichtentiteit is de lengte na gzip-compressie.
In specifieke HTTP-interacties is de verkrijgen van de berichtlengte vooral gebaseerd op de volgende regels:
Als de reactie 1xx, 204, 304 of headrequest is, wordt de inhoud van de berichtentiteit direct genegeerd.
Als er Transfer-Encoding is, heeft de methode in Transfer-Encoding de voorkeur om de overeenkomstige lengte te vinden. Bijvoorbeeld het Chunked-model.
"Als er een Inhoud-Lengte in de kop is, dan vertegenwoordigt deze Inhoud-Lengte zowel de lichaamslengte als de transmissielengte. Als de entiteitslengte en overdrachtslengte niet gelijk zijn (bijvoorbeeld Transfer-Encoding is ingesteld), dan kan de Inhoud-Lengte niet worden ingesteld.Als Transfer-Encoding is ingesteld, wordt Content-Length genegeerd”。 Het voordeel van deze zinsvertaling is dat er maar één punt is: met Transfer-Encoding kan er geen Content-Length zijn.
Bereiktransmissie. Ik lette niet op, ik las het niet in detail :)
Het sluiten van de verbinding via de server bepaalt de lengte van het verzonden bericht. (De verzoeker kan het einde van het verzoeklichaam niet aangeven door de verbinding te sluiten, omdat de server dan geen kans meer heeft om te reageren.) Deze situatie komt voornamelijk overeen met korte verbindingen, oftewel de niet-levende modus.
HTTP 1.1 moet chunk-modus ondersteunen. Omdat wanneer de lengte van het bericht onzeker is, deze situatie via het chunk-mechanisme kan worden afgehandeld.
In de header met de inhoud van het bericht, als er een inhouds-lengte veld is, moet de overeenkomstige waarde van het veld exact overeenkomen met de lengte van het berichtonderwerp.
"De entiteitslengte van een bericht is de lengte van het berichtlichaam voordat er overdrachtscoderingen zijn toegepast"
Dat wil zeggenAls er een stuk is, kan er geen inhoudslengte zijn 。
Het persistente verbindingsmechanisme van HTTP/1.0 werd later geïntroduceerd en wordt geïmplementeerd via de header Connection: keep-alive, die zowel door de server als de client kan worden gebruikt om elkaar te vertellen dat ze de TCP-verbinding niet hoeven te verbreken na het verzenden van de gegevens voor later gebruik.HTTP/1.1 vereist dat alle verbindingen persistent zijn，Tenzij je expliciet Connection: dicht bij de header toevoegt.。 Dus in feite heeft het Connection-headerveld in HTTP/1.1 niet langer de waarde van keep-alive, maar door historische redenen behouden veel webservers en browsers nog steeds de gewoonte om Connection: keep-alive naar HTTP/1.1 lange verbindingen te sturen.
In feite kunnen de laatste paar bijna genegeerd worden, en een korte samenvatting is als volgt:
1. Inhoud-Lengte: Als deze bestaat en geldig is, moet deze exact gelijk zijn aan de transmissielengte van de berichtinhoud. (Getest om te korten als het te kort is, en te lang om een time-out te veroorzaken.) ）
2. Als er Transfer-Encoding is (de focus is gehuld), kan er geen Content-Length in de header staan, en dit wordt genegeerd.
3. Als een korte verbinding wordt gebruikt, kan de transmissielengte van het bericht direct worden bepaald door de verbinding via de server te sluiten. (Dit is makkelijk te begrijpen)
In combinatie met andere functies van het HTTP-protocol ondersteunde Http1.1 bijvoorbeeld geen keep alive. Dan kunnen de volgende conclusies worden getrokken:
1. In Http 1.0 en eerdere versies is het veld voor inhoudslengte optioneel.
2. In http1.1 en latere versies. Als je in leven blijft, moeten content-length en chunk één van de twee zijn. Als het niet in leven wordt gehouden, is het hetzelfde als http1.0. inhoudslengte.
|
Geplaatst op 24-09-2019 15:53:29
|
|
|
