Innehållslängd används för att beskriva överföringslängden av meddelandekroppen. I HTTP-protokollet finns det en skillnad mellan längden på meddelandeenheten och transmissionslängden på meddelandeenheten, till exempel under gzip-komprimering är längden på meddelandeenheten längden före komprimeringen, och transmissionslängden på meddelandeenheten är längden efter gzip-komprimeringen.
I specifika HTTP-interaktioner baseras klienten huvudsakligen på följande regler hur den erhåller meddelandelängden:
Om svaret är 1xx, 204, 304 eller head-request, ignoreras innehållet i meddelandeentiteten direkt.
Om det finns Överföringskodning föredras metoden i Överföringskodning för att hitta motsvarande längd. Till exempel Chunked-modellen.
"Om det finns en innehållslängd i huvudet, representerar denna innehållslängd både kroppslängden och transmissionslängden. Om entitetslängden och överföringslängden inte är lika (t.ex. överföringskodning är satt), kan inte innehållslängden sättas.Om Transfer-Encoding är satt, kommer Content-Length att ignoreras”。 Fördelen med denna meningsöversättning är att det bara finns en punkt: med överföringskodning kan det inte finnas någon innehållslängd.
Räckviddsöverföring. Jag var inte uppmärksam, jag läste den inte i detalj :)
Att stänga anslutningen via servern bestämmer längden på det meddelande som skickas. (Begäraren kan inte ange slutet på förfrågningskroppen genom att stänga anslutningen, eftersom detta skulle lämna servern utan möjlighet att fortsätta svara.) Denna situation motsvarar främst korta anslutningar, dvs. icke-keep-alive-läge.
HTTP 1.1 måste stödja chunk-läge. Eftersom när meddelandets längd är osäker kan denna situation hanteras genom chunk-mekanismen.
I huvudet som innehåller meddelandets innehåll, om det finns ett fält med innehållslängd, måste det motsvarande värdet av fältet exakt matcha längden på meddelandets ämne.
"Entitetslängden på ett meddelande är längden på meddelandekroppen innan några överföringskodningar har tillämpats"
Det ärOm det finns en bit kan det inte finnas någon innehållslängd 。
Den persistenta anslutningsmekanismen i HTTP/1.0 introducerades senare och implementeras via headern Connection: keep-alive, som kan användas av både servern och klienten för att meddela varandra att de inte behöver koppla bort TCP-anslutningen efter att ha skickat data för senare användning.HTTP/1.1 kräver att alla anslutningar är beständiga，Om du inte uttryckligen lägger till Connection: nära headern:。 Så i själva verket har Connection-headerfältet i HTTP/1.1 inte längre värdet av keep-alive, men av historiska skäl behåller många webbservrar och webbläsare fortfarande vanan att skicka Connection: keep-alive till HTTP/1.1-långa anslutningar.
Faktum är att de sista kan nästan ignoreras, och en kort sammanfattning är följande:
1. Innehåll-längd: Om den finns och är giltig måste den vara exakt densamma som överföringstiden för meddelandets innehåll. (Testat för att trunkera om det var för kort, och för långt för att orsaka timeout.) ）
2. Om det finns Överföringskodning (fokuset är chunked) kan det inte finnas någon Innehållslängd i headern, och den ignoreras.
3. Om en kort anslutning används kan meddelandets överföringslängd bestämmas direkt genom att stänga anslutningen via servern. (Det här är lätt att förstå)
I kombination med andra funktioner i HTTP-protokollet stödde till exempel inte Http1.1 keep alive. Därefter kan följande slutsatser dras:
1. I Http 1.0 och tidigare versioner är innehållslängdsfältet valfritt.
2. I http1.1 och senare versioner. Om du håller dig vid liv måste innehållslängd och chunk vara en av de två. Om det inte hålls vid liv är det samma som http1.0. innehållslängd.
|
Publicerad på 2019-09-24 15:53:29
|
|
|
