Lungimea conținutului este folosită pentru a descrie lungimea de transfer a corpului mesajului. În protocolul HTTP, există o diferență între lungimea entității mesajului și lungimea de transmisie a entității mesajului, de exemplu, sub compresia gzip, lungimea entității mesajului este lungimea înainte de compresie, iar lungimea de transmisie a entității mesajului este lungimea după compresia gzip.
În anumite interacțiuni HTTP, modul în care clientul obține lungimea mesajului se bazează în principal pe următoarele reguli:
Dacă răspunsul este 1xx, 204, 304 sau cererea principală, conținutul entității mesajului este ignorat direct.
Dacă există Transfer-Encoding, metoda din Transfer-Encoding este preferată pentru a găsi lungimea corespunzătoare. De exemplu, modelul Chunked.
"Dacă există o lungime de conținut în cap, atunci această lungime de conținut reprezintă atât lungimea corpului, cât și lungimea transmisiei. Dacă lungimea entității și lungimea de transfer nu sunt egale (de exemplu, Transfer-Encoding este setat), atunci Conținut-Lungimea nu poate fi setată.Dacă Transfer-Encoding este setat, atunci Conținut-Lungimea va fi ignorată”。 Avantajul acestei traduceri a propozițiilor este că există un singur punct: cu Transfer-Encoding, nu poate exista Lungimea Conținutului.
Transmisie de distanță. Nu am fost atentă, nu am citit-o în detaliu :)
Închiderea conexiunii prin server determină lungimea mesajului transmis. (Solicitantul nu poate indica sfârșitul corpului cererii prin închiderea conexiunii, deoarece acest lucru ar lăsa serverul fără nicio șansă de a continua să răspundă.) Această situație corespunde în principal conexiunilor scurte, adică modul non-keep-alive.
HTTP 1.1 trebuie să suporte modul chunk. Pentru că atunci când lungimea mesajului este incertă, această situație poate fi gestionată prin mecanismul chunk-ului.
În antetul care conține conținutul mesajului, dacă există un câmp de lungime a conținutului, valoarea corespunzătoare a câmpului trebuie să corespundă exact lungimii subiectului mesajului.
"Lungimea entității unui mesaj este lungimea corpului mesajului înainte ca orice codare de transfer să fie aplicată"
AdicăDacă există un chunk, nu poate exista o lungime a conținutului 。
Mecanismul de conexiune persistentă HTTP/1.0 a fost introdus ulterior și este implementat prin antetul Connection: keep-alive, care poate fi folosit atât de server, cât și de client pentru a se informa reciproc că nu trebuie să deconecteze conexiunea TCP după trimiterea datelor pentru utilizare ulterioară.HTTP/1.1 cere ca toate conexiunile să fie persistente，Decât dacă adaugi explicit Connection: aproape de antet。 Astfel, de fapt, câmpul de antet Connection din HTTP/1.1 nu mai are valoarea de keep-alive, dar, din motive istorice, multe servere web și browsere încă păstrează obiceiul de a trimite conexiuni Connection: keep-alive către HTTP/1.1 long connections.
De fapt, ultimele câteva pot fi aproape ignorate, iar un scurt rezumat este următorul:
1. Lungimea conținutului: Dacă există și este validă, trebuie să fie exact aceeași cu lungimea de transmisie a conținutului mesajului. (Testat să scurteze dacă este prea scurt și prea lung pentru a provoca time-out.) ）
2. Dacă există Transfer-Encoding (focalizarea este fragmentată), nu poate exista Conținut-Lungime în antet, iar aceasta va fi ignorată.
3. Dacă se folosește o conexiune scurtă, lungimea de transmisie a mesajului poate fi determinată direct prin închiderea conexiunii prin server. (Este ușor de înțeles)
Combinat cu alte funcționalități ale protocolului HTTP, de exemplu, Http1.1 nu suporta menținerea activă. Atunci se pot trage următoarele concluzii:
1. În Http 1.0 și versiunile anterioare, câmpul de lungime a conținutului este opțional.
2. În http1.1 și versiunile ulterioare. Dacă rămâi în viață, atunci lungimea conținutului și bucata trebuie să fie una dintre cele două. Dacă nu este menținut în viață, este la fel ca http1.0. conținut-lungime.
|
Postat pe 24.09.2019 15:53:29
|
|
|
