Innholdslengde brukes for å beskrive overføringslengden til meldingsinnholdet. I HTTP-protokollen er det en forskjell mellom lengden på meldingsenheten og overføringslengden på meldingsenheten, for eksempel under gzip-komprimering er lengden på meldingsenheten lengden før komprimering, og overføringslengden til meldingsenheten er lengden etter gzip-komprimering.
I spesifikke HTTP-interaksjoner er måten klienten får meldingslengden på hovedsakelig basert på følgende regler:
Hvis svaret er 1xx, 204, 304 eller head request, ignoreres innholdet i meldingsenheten direkte.
Hvis det finnes Transfer-Encoding, foretrekkes metoden i Transfer-Encoding for å finne den tilsvarende lengden. For eksempel Chunked-modellen.
"Hvis det finnes en innholds-lengde i hodet, representerer denne innholds-lengden både kroppslengden og overføringslengden. Hvis entitetslengden og overføringslengden ikke er like (f.eks. overføringskoding settes), kan ikke innholdslengden settes.Hvis Transfer-Encoding er satt, vil Innhold-Lengde bli ignorert”。 Fordelen med denne setningsoversettelsen er at det bare finnes ett poeng: med Transfer-Encoding kan det ikke være noe Innhold-Lengde.
Rekkeviddeoverføring. Jeg fulgte ikke med, jeg leste det ikke i detalj :)
Å lukke forbindelsen gjennom serveren bestemmer lengden på meldingen som sendes. (Forespørsleren kan ikke angi slutten på forespørselskroppen ved å lukke forbindelsen, da dette vil gi serveren ingen mulighet til å fortsette å svare.) Denne situasjonen tilsvarer hovedsakelig korte forbindelser, altså ikke-keep-alive-modus.
HTTP 1.1 må støtte chunk-modus. Fordi når lengden på meldingen er usikker, kan denne situasjonen håndteres gjennom chunk-mekanismen.
I headeren som inneholder meldingsinnholdet, hvis det finnes et innholds-lengdefelt, må den tilsvarende verdien av feltet nøyaktig samsvare med lengden på meldingsemnet.
"Entitetslengden til en melding er lengden på meldingskroppen før noen overføringskoder er implementert"
Det vil siHvis det finnes en bit, kan det ikke være noen innholdslengde 。
Den vedvarende tilkoblingsmekanismen HTTP/1.0 ble introdusert senere, og den implementeres gjennom headeren Connection: keep-alive, som både server og klient kan bruke for å fortelle hverandre at de ikke trenger å koble fra TCP-tilkoblingen etter å ha sendt dataene for senere bruk.HTTP/1.1 krever at alle tilkoblinger er vedvarende，Med mindre du eksplisitt legger til Connection: nær headeren。 Så faktisk har ikke Connection-headerfeltet i HTTP/1.1 lenger verdien av keep-alive, men av historiske grunner beholder mange webservere og nettlesere fortsatt vanen med å sende Connection: keep-alive til HTTP/1.1 lange forbindelser.
Faktisk kan de siste nesten ignoreres, og en kort oppsummering er som følger:
1. Innhold-lengde: Hvis den eksisterer og er gyldig, må den være nøyaktig lik overføringslengden til meldingens innhold. (Testet for å avkorte hvis det var for kort, og for langt til å forårsake timeout.) ）
2. Hvis det finnes Transfer-Encoding (fokuset er chunked), kan det ikke være Innhold-Lengde i headeren, og det vil bli ignorert.
3. Hvis en kort forbindelse brukes, kan overføringslengden på meldingen bestemmes direkte ved å lukke forbindelsen gjennom serveren. (Dette er lett å forstå)
Kombinert med andre funksjoner i HTTP-protokollen, for eksempel, støttet ikke Http1.1 hold alive. Deretter kan følgende konklusjoner trekkes:
1. I Http 1.0 og tidligere versjoner er innholdet valgfritt.
2. I http1.1 og senere versjoner. Hvis du holder deg i live, må innholdslengde og chunk være en av de to. Hvis det ikke holdes i live, er det det samme som http1.0. innholds-lengde.
|
Publisert på 24.09.2019 15:53:29
|
|
|
