Content-Lengthia käytetään kuvaamaan viestin rungon siirtopituutta. HTTP-protokollassa viestientiteettien pituuden ja viestientiteettien lähetyspituuden välillä on ero, esimerkiksi gzip-pakkauksessa viestientiteetti on pituus ennen pakkausta ja viestientiteettien lähetyspituus on pituus gzip-pakkauksen jälkeen.
Erityisissä HTTP-vuorovaikutuksissa asiakas saa viestin pituuden pääasiassa seuraaviin sääntöihin:
Jos vastaus on 1xx, 204, 304 tai head-pyyntö, viestin sisältö jätetään suoraan huomiotta.
Jos Transfer-Encoding on olemassa, Transfer-Encoding -menetelmä on suositeltavampi vastaavan pituuden löytämiseksi. Esimerkiksi Chunked-malli.
"Jos päässä on Content-Length, niin tämä Content-Length edustaa sekä kehon pituutta että lähetyspituutta. Jos entiteettipituus ja siirtopituus eivät ole yhtä suuret (esim. siirto-koodaus on asetettu), sisältöpituutta ei voi asettaa.Jos siirtokoodaus on asetettu, sisältöpituus jätetään huomiotta”。 Tämän lausekäännöksen etuna on, että on vain yksi asia: siirtokoodauksessa ei voi olla sisällönpituutta.
Kantaman siirto. En kiinnittänyt huomiota, en lukenut sitä yksityiskohtaisesti :)
Yhteyden sulkeminen palvelimen kautta määrittää lähetettävän viestin pituuden. (Pyytäjä ei voi ilmoittaa pyynnön rungon loppua sulkemalla yhteyttä, sillä se jättäisi palvelimelle mahdollisuuden jatkaa vastaamista.) Tämä tilanne liittyy pääasiassa lyhyisiin yhteyksiin, eli ei-elävään tilaan.
HTTP 1.1:n täytyy tukea chunk-tilaa. Koska kun viestin pituus on epävarma, tilanne voidaan hoitaa chunk-mekanismin kautta.
Viestin sisältöä sisältävässä otsikossa, jos on sisältöpituuskenttä, kentän vastaavan arvon on täsmälleen vastattava viestin aiheen pituutta.
"Viestin entiteettipituus on viestin rungon pituus ennen siirtokoodauksen käyttöönottoa"
Tuo onJos on lohko, sisältöpituutta ei voi olla 。
HTTP/1.0:n pysyvä yhteysmekanismi otettiin käyttöön myöhemmin, ja se toteutetaan otsikolla Connection: keep-alive, jota sekä palvelin että asiakas voivat käyttää kertoakseen toisilleen, ettei TCP-yhteyttä tarvitse katkaista sen jälkeen, kun data on lähetetty myöhempää käyttöä varten.HTTP/1.1 vaatii, että kaikki yhteydet ovat pysyviä，Ellet lisää nimenomaisesti Connection: lähellä otsikkoa。 Näin ollen HTTP/1.1:n Connection-otsikkokenttä ei enää ole arvokas kuin keep-alive, mutta historiallisista syistä monet verkkopalvelimet ja selaimet säilyttävät edelleen tavan lähettää Connection: keep-alive -tiedostoa HTTP/1.1-pitkille yhteyksille.
Itse asiassa viimeiset muutamat voi melkein jättää huomiotta, ja lyhyt yhteenveto on seuraava:
1. Sisältöpituus: Jos se on olemassa ja pätevä, sen on oltava täsmälleen sama kuin viestin sisällön lähetyspituus. (Testattiin lyhentämään, jos se on liian lyhyt, ja liian pitkä aikalisän aiheuttamiseksi.) ）
2. Jos Transfer-Encoding (fokus on lohkottu), otsikossa ei voi olla Content-Lengthia, ja se jätetään huomiotta.
3. Jos käytetään lyhyttä yhteyttä, viestin lähetyspituus voidaan määrittää suoraan sulkemalla yhteys palvelimen kautta. (Tämä on helppo ymmärtää)
Yhdistettynä muihin HTTP-protokollan ominaisuuksiin esimerkiksi Http1.1 ei tukenut Keep alive -toimintoa. Tällöin voidaan tehdä seuraavat johtopäätökset:
1. Http 1.0:ssa ja vanhemmissa versioissa sisältöpituuskenttä on valinnainen.
2. http1.1 ja myöhemmissä versioissa. Jos pysyt hengissä, sisällön pituus ja osa ovat varmasti yksi näistä kahdesta. Jos sitä ei pidetä elossa, se on sama kuin http1.0. sisältö-pituus.
|
Julkaistu 24.9.2019 15.53.29
|
|
|
