A tartalom-hossz az üzenettest átviteli hosszának leírására szolgál. A HTTP protokollban különbség van az üzenet entitás hossza és az üzenet entitás hossza között, például gzip tömörítés esetén az üzenetentitás hossza a tömörítés előtti hossz, az üzenet entitás hossza pedig a gzip tömörítés utáni hossz.
Konkrét HTTP interakciókban az ügyfél üzenethosszának megszerzése főként a következő szabályokon alapul:
Ha a válasz 1xx, 204, 304 vagy fejkérés, az üzenet entitás tartalmát közvetlenül figyelmen kívül hagyják.
Ha létezik Átvitel-kódolás, akkor a Transzfer-Kódolás módszerét előnyben részesítik a megfelelő hosszúság megtalálásához. Például a Chunked modell.
"Ha a fejben van Tartalomhossz, akkor ez a Tartalomhossz mind a testhosszt, mind az átviteli hosszt jelenti. Ha az entitás hossza és az átviteli hossz nem egyenlő (például az áthelyezés-kódolás beállított), akkor a tartalomhossz nem állítható be.Ha az átvitel-kódolás be van állítva, akkor a tartalomhosszat figyelmen kívül hagyjuk”。 Ennek a mondatfordításnak az előnye, hogy csak egy pont van: a transzfer-kódolás esetén nem lehet tartalomhossz.
Távolsági átvitel. Nem figyeltem, nem olvastam részletesen :)
A szerveren keresztül történő kapcsolat lezárása határozza meg az üzenet továbbításának időtartamát. (A kérő nem jelezheti a kérés test végét a kapcsolat lezárásával, mert így a szervernek nem lenne esélye a válaszadás folytatására.) Ez a helyzet főként rövid kapcsolatokra vonatkozik, azaz nem életben tartás módra.
A HTTP 1.1-nek támogatnia kell a chunk módot. Mert ha az üzenet hossza nem egyértelmű, ezt a helyzetet a chunk mechanizmuson keresztül lehet kezelni.
Az üzenet tartalmát tartalmazó fejlécben, ha van tartalomhosszú mező, a mező megfelelő értékének pontosan egyeznie kell az üzenettéma hosszával.
"Az üzenet entitáshossza az üzenettest hossza, mielőtt bármilyen átviteli kódolást alkalmaztak"
AzHa van egy darab, akkor nem lehet tartalomhossz 。
A HTTP/1.0 tartós kapcsolati mechanizmusát később vezették be, és a Connection: keep-alive fejlécen keresztül valósítható meg, amelyet mind a szerver, mind a kliens használhat arra, hogy közöljék egymással, nem kell megszakítani a TCP kapcsolatot az adatok későbbi használatra való elküldése után.Az HTTP/1.1 megköveteli, hogy minden kapcsolat tartós legyen，Hacsak nem adsz kifejezetten hozzá a Connection: közel a fejléchez。 Tehát valójában a HTTP/1.1 Connection fejlécének mezője már nem rendelkezik a keep alive értékével, de történelmi okokból sok webszerver és böngésző továbbra is megszokta a Connection: keep-alive küldését HTTP/1.1 hosszú kapcsolatokra.
Valójában az utóbbi néhány szinte figyelmen kívül hagyható, és egy rövid összefoglaló a következő:
1. Tartalom-hossz: Ha létezik és érvényes, pontosan ugyanannyinak kell lennie, mint az üzenet tartalmának továbbítási hossza. (Tesztelték, hogy rövidítsék, ha túl rövid, és túl hosszú ahhoz, hogy időkérést okozz.) ）
2. Ha van átvitel-kódolás (a fókusz darabos), akkor a fejlécben nem lehet tartalomhossz, és ezt figyelmen kívül hagyják.
3. Ha rövid kapcsolatot használnak, az üzenet átviteli hossza közvetlenül meghatározható a szerveren keresztüli kapcsolat lezárásával. (Ez könnyen érthető)
Például a HTTP protokoll más funkcióival együtt a Http1.1 nem támogatta a Keep Live funkciót. Ezután a következő következtetések levonhatók:
1. A Http 1.0 és korábbi verziókban a tartalomhossz mező opcionális.
2. A http1.1 és későbbi verziókban. Ha életben maradsz, akkor a tartalom hossza és a rész az egyik. Ha nem tartják életben, akkor ugyanaz, mint a http1.0. tartalom-hosszúság.
|
Közzétéve 2019. 09. 24. 15:53:29
|
|
|
