Satura garums tiek izmantots, lai aprakstītu ziņojuma pamatteksta pārsūtīšanas garumu. HTTP protokolā pastāv atšķirība starp ziņojuma entītijas garumu un ziņojuma entītijas pārraides garumu, piemēram, gzip saspiešanas gadījumā ziņojuma entītijas garums ir garums pirms saspiešanas, un ziņojuma entītijas pārraides garums ir garums pēc gzip saspiešanas.
Konkrētās HTTP mijiedarbībās tas, kā klients iegūst ziņojuma garumu, galvenokārt ir balstīts uz šādiem noteikumiem:
Ja atbilde ir 1xx, 204, 304 vai galvas pieprasījums, ziņojuma entītijas saturs tiek tieši ignorēts. Ja ir Transfer-Encoding, Transfer-Encoding metode ir vēlama, lai atrastu atbilstošo garumu. Piemēram, Chunked modelis. "Ja galvā ir satura garums, tad šis satura garums atspoguļo gan ķermeņa garumu, gan pārraides garumu. Ja entītijas garums un pārsūtīšanas garums nav vienādi (piemēram, ir iestatīts pārsūtīšanas kodējums), tad satura garumu nevar iestatīt.Ja ir iestatīts Transfer-Encoding, tad Content-Length tiks ignorēts”。 Šī teikuma tulkojuma priekšrocība ir tā, ka ir tikai viens punkts: ar pārsūtīšanas kodēšanu nevar būt satura garuma. Diapazona pārraide. Es nepievērsu uzmanību, es to detalizēti neizlasīju :) Savienojuma slēgšana caur serveri nosaka pārraidāmā ziņojuma garumu. (Pieprasītājs nevar norādīt pieprasījuma pamatteksta beigas, slēdzot savienojumu, jo tas neļautu serverim turpināt atbildēt.) Šī situācija galvenokārt atbilst īsiem savienojumiem, t.i., neuzturēšanas režīmam. HTTP 1.1 ir jāatbalsta gabalu režīms. Jo, ja ziņojuma garums ir neskaidrs, šo situāciju var risināt, izmantojot gabalu mehānismu. Galvenē, kurā ir ziņojuma saturs, ja ir lauks satura garums, atbilstošajai lauka vērtībai precīzi jāatbilst ziņojuma tēmas garumam. "Ziņojuma vienības garums ir ziņojuma pamatteksta garums pirms jebkādu pārsūtīšanas kodu piemērošanas" Tas irJa ir gabals, nevar būt satura garuma 。
HTTP / 1.0 pastāvīgais savienojuma mehānisms tika ieviests vēlāk, un tas tiek īstenots, izmantojot galveni Savienojums: uzturēt dzīvu, ko var izmantot gan serveris, gan klients, lai pateiktu viens otram, ka viņiem nav nepieciešams atvienot TCP savienojumu pēc datu nosūtīšanas vēlākai lietošanai.HTTP/1.1 pieprasa, lai visi savienojumi būtu pastāvīgi,Ja vien nepievienojat skaidri Savienojums: tuvu galvenei。 Tātad faktiski HTTP/1.1 laukam Connection header vairs nav vērtības keep alive, bet vēsturisku iemeslu dēļ daudzi tīmekļa serveri un pārlūkprogrammas joprojām saglabā ieradumu sūtīt Connection: keep-alive uz HTTP/1.1 gariem savienojumiem.
Patiesībā pēdējos dažus var gandrīz ignorēt, un īss kopsavilkums ir šāds:
1. Satura garums: ja tas pastāv un ir derīgs, tam jābūt tieši tādam pašam kā ziņojuma satura pārraides garumam. (Pārbaudīts, lai saīsinātu, ja tas ir pārāk īss un pārāk ilgs, lai izraisītu taimautu.) ) 2. Ja ir pārsūtīšanas kodējums (fokuss ir sadalīts), galvenē nevar būt satura garuma, un tas tiks ignorēts. 3. Ja tiek izmantots īss savienojums, ziņojuma pārraides garumu var noteikt tieši, slēdzot savienojumu caur serveri. (Tas ir viegli saprotams) Apvienojumā ar citām HTTP protokola funkcijām, piemēram, Http1.1 neatbalstīja dzīvības saglabāšanu. Tad var izdarīt šādus secinājumus: 1. Http 1.0 un vecākās versijās satura garuma lauks nav obligāts. 2. http1.1 un jaunākās versijās. Ja jūs saglabājat dzīvību, tad satura garumam un gabalam jābūt vienam no diviem. Ja tas netiek saglabāts dzīvs, tas ir tāds pats kā http1.0. satura garums.
|