Długość treści jest używana do opisu długości transferu tła wiadomości. W protokole HTTP istnieje różnica między długością jednostki wiadomości a długością transmisji tej jednostki; na przykład przy kompresji gzip długość jednostki wiadomości to długość przed kompresją, a długość transmisji jednostki wiadomości to długość po kompresji gzip.
W konkretnych interakcjach HTTP sposób uzyskiwania przez klienta długości wiadomości opiera się głównie na następujących regułach:
Jeśli odpowiedź to 1xx, 204, 304 lub żądanie głowy, treść jednostki wiadomości jest bezpośrednio ignorowana.
Jeśli istnieje kodowanie transferowe, preferowana jest metoda w kodowaniu transferowym, aby znaleźć odpowiednią długość. Na przykład model Chunked.
"Jeśli w głowie jest Content-Length, to ta Content-Length reprezentuje zarówno długość ciała, jak i długość transmisji. Jeśli długość jednostki i długość transferu nie są równe (np. ustawione jest kodowanie transferowe), to nie można ustawić długości zawartości.Jeśli zostanie ustawione Transfer-Encoding (Transfer-Enkodiranie), to Content-Length zostanie zignorowane”。 Zaletą tego tłumaczenia zdań jest to, że jest tylko jeden punkt: przy kodowaniu transferowym nie może istnieć długość treści.
Transmisja zasięgu. Nie zwracałem uwagi, nie czytałem tego szczegółowo, :)
Zamknięcie połączenia przez serwer determinuje długość przesyłanej wiadomości. (Zgłaszający nie może wskazać końca ciała żądania poprzez zamknięcie połączenia, ponieważ serwer nie miałby szansy na dalszą odpowiedź.) Ta sytuacja głównie odpowiada krótkim połączeniom, czyli trybowi non-keep-alive.
HTTP 1.1 musi obsługiwać tryb chunk. Ponieważ gdy długość wiadomości jest niepewna, sytuację tę można rozwiązać za pomocą mechanizmu chunk.
W nagłówku zawierającym treść wiadomości, jeśli istnieje pole długości treści, odpowiadająca wartość pola musi dokładnie odpowiadać długości tematu wiadomości.
"Długość encji wiadomości to długość ciała wiadomości przed zastosowaniem jakichkolwiek kodów transferowych"
CzyliJeśli jest fragment, nie może być długości treści 。
Mechanizm trwałego połączenia HTTP/1.0 został wprowadzony później i jest realizowany za pomocą nagłówka Connection: keep-alive, który może być używany zarówno przez serwer, jak i klienta, aby przekazać sobie nawzajem, że nie muszą rozłączać połączenia TCP po przesłaniu danych do późniejszego użytku.HTTP/1.1 wymaga, aby wszystkie połączenia były trwałe，Chyba że wyraźnie dodasz Connection: blisko nagłówka。 W rzeczywistości pole nagłówka Connection w HTTP/1.1 nie ma już wartości keep-alive, ale z powodów historycznych wiele serwerów i przeglądarek nadal zachowuje zwyczaj wysyłania długich połączeń Connection: keep-alive do HTTP/1.1.
W rzeczywistości ostatnie kilka można niemal zignorować, a krótkie podsumowanie brzmi następująco:
1. Długość treści: Jeśli istnieje i jest ważna, musi być dokładnie taka sama jak długość transmisji zawartości wiadomości. (Testowano, by skracać, jeśli jest zbyt krótko i zbyt długo, by spowodować przerwę.) ）
2. Jeśli istnieje Transfer-Encoding (fokus jest podzielony na fragmenty), w nagłówku nie może być Content-Length i zostanie on zignorowany.
3. Jeśli użyte jest krótkie połączenie, długość transmisji wiadomości można określić bezpośrednio poprzez zamknięcie połączenia przez serwer. (To łatwe do zrozumienia)
W połączeniu z innymi funkcjami protokołu HTTP, na przykład, Http1.1 nie wspierał funkcji Keep Alive. Można wyciągnąć następujące wnioski:
1. W wersjach Http 1.0 i wcześniejszych pole długości treści jest opcjonalne.
2. W wersjach http1.1 i nowszych. Jeśli pozostajesz przy życiu, to długość zawartości i fragment muszą być jednym z tych dwóch. Jeśli nie jest to Keep Alive, to jest to samo co http1.0. Długość treści.
|
Opublikowano 24.09.2019 15:53:29
|
|
|
