Indhold-længde bruges til at beskrive overførselslængden af beskedens krop. I HTTP-protokollen er der en forskel mellem længden af meddelelsesenheden og transmissionslængden af meddelelsesenheden, for eksempel under gzip-komprimering er længden af meddelelsesenheden længden før komprimeringen, og transmissionslængden af meddelelsesenheden er længden efter gzip-komprimering.
I specifikke HTTP-interaktioner er måden, hvorpå klienten opnår beskedlængden, hovedsageligt baseret på følgende regler:
Hvis svaret er 1xx, 204, 304 eller hovedanmodning, ignoreres indholdet i beskedenheden direkte.
Hvis der er Transfer-Encoding, foretrækkes metoden i Transfer-Encoding for at finde den tilsvarende længde. For eksempel Chunked-modellen.
"Hvis der er en indholdslængde i hovedet, repræsenterer denne indholdslængde både kropslængden og transmissionslængden. Hvis entitetslængden og overførselslængden ikke er ens (f.eks. Transfer-Encoding er sat), kan Indhold-Længden ikke sættes.Hvis Transfer-Encoding er sat, vil Content-Length blive ignoreret”。 Fordelen ved denne sætningsoversættelse er, at der kun er ét punkt: med Transfer-Encoding kan der ikke være nogen Indholdslængde.
Rækkeviddetransmission. Jeg fulgte ikke med, jeg læste det ikke i detaljer :)
At lukke forbindelsen gennem serveren bestemmer længden af den sendte besked. (Requesteren kan ikke angive afslutningen på anmodningskroppen ved at lukke forbindelsen, da det ville efterlade serveren uden mulighed for at fortsætte med at svare.) Denne situation svarer hovedsageligt til korte forbindelser, dvs. ikke-keep-alive tilstand.
HTTP 1.1 skal understøtte chunk-tilstand. For når længden af beskeden er usikker, kan denne situation håndteres gennem chunk-mekanismen.
I headeren, der indeholder beskedens indhold, hvis der findes et indholdslængdefelt, skal den tilsvarende værdi af feltet nøjagtigt matche længden af beskedemnet.
"Entitetslængden af en besked er længden af meddelelseskroppen, før nogen transfer-kodninger er blevet anvendt"
Det erHvis der er et stykke, kan der ikke være nogen indholdslængde 。
Den vedvarende forbindelsesmekanisme HTTP/1.0 blev introduceret senere, og den implementeres gennem headeren Connection: keep-alive, som både serveren og klienten kan bruge til at fortælle hinanden, at de ikke behøver at afbryde TCP-forbindelsen efter at have sendt dataene til senere brug.HTTP/1.1 kræver, at alle forbindelser er vedvarende，Medmindre du eksplicit tilføjer Connection: tæt på headeren。 Så faktisk har Connection-headerfeltet i HTTP/1.1 ikke længere værdien af keep-alive, men af historiske årsager bevarer mange webservere og browsere stadig vanen med at sende Connection: keep-alive til HTTP/1.1 lange forbindelser.
Faktisk kan de sidste få næsten ignoreres, og en kort opsummering er som følger:
1. Indhold-længde: Hvis den eksisterer og er gyldig, skal den være nøjagtig den samme som transmissionslængden af beskedens indhold. (Testet for at afkorte, hvis det var for kort, og for langt til at forårsage timeout.) ）
2. Hvis der er Transfer-Encoding (fokus er chunket), kan der ikke være nogen Indholdslængde i headeren, og den vil blive ignoreret.
3. Hvis en kort forbindelse anvendes, kan transmissionslængden af beskeden bestemmes direkte ved at lukke forbindelsen gennem serveren. (Det er let at forstå)
Kombineret med andre funktioner i HTTP-protokollen understøttede Http1.1 for eksempel ikke keep alive. Derefter kan følgende konklusioner drages:
1. I Http 1.0 og tidligere versioner er indholdslængdefeltet valgfrit.
2. I http1.1 og senere versioner. Hvis du holder dig i live, skal indholdslængde og chunk være en af de to. Hvis det ikke holdes i live, er det det samme som http1.0. indholdslængde.
|
Opslået på 24/09/2019 15.53.29
|
|
|
