לייענען דעם אַרויפֿלאָד אין שטיקער פֿאָדערט נישט קיין chunked HTTP

ניין. אַ קליענט קען לייענען אַ גרויסע טעקע אין קליינע בופֿערס און שיקן זי מיט אַ באַקאַנטער Content-Length. באַגרענעצטע לייענען קאָנטראָלירן די זיכּרון־ניצונג; HTTP־פֿראַימינג זאָגט דעם באַקומער וווּ דער קערפּער פֿון דער בקשה ענדיקט זיך.

אַ סטאַבילע טעקע וועמענס בייט־לענג די HTTP־ביבליאָטעק ווייסט איז אַנדערש פֿון אַ גענעראַטאָר וואָס פּראָדוצירט אַן אומבאַקאַנטן כּלל דאַטן. ניצט די פֿאַרמאָג־צובינד פֿון דער ביבליאָטעק פֿאַר ביידע מקורים. איר דאַרפֿט נישט צונויפֿשטעלן די גאַנצע טעקע אין אַ שטריק נאָר כּדי אָנצוגעבן אַ לענג.

פֿאַר HTTP/1.1, באַקוקט די פֿראַימינג וואָס איז טאַקע געשיקט געוואָרן: Content-Length אָדער chunked transfer coding לויט די כּללים פֿון דער פּראָטאָקאָל. Chunked־קאָדירן לייגט צו גרייס־צייכנס אינדרויסן פֿון דער טעקע־אינהאַלט. פֿאַרבינדט נישט קעגנזייטיקע פֿראַימינג־פֿעלדער און שאַצט נישט קיין לענג כּדי איבערצורעדן אַ פּראָקסי אָנצונעמען דעם אַרויפֿלאָד.

אויב אַן אַרויפֿלאָד דורך אַ פּראָקסי דורכפֿאַלט, פֿאַרשרייב די HTTP־ווערסיע, דעם מקור פֿון קערפּער און די ערשטע אָפּוואַרפֿונג. אַ 411 ענטפֿער טייט אויף אַן אַנדער אויספֿאָרשונג ווי אַ פֿאַרבינדונג וואָס שליסט זיך אינמיטן קערפּער. אויב אַנשטאָט דעם דורכפֿאַלן די ווידערהאָלונגען פֿון אָטענטיפֿיקאַציע, פּרוּווט צי דער אַרויפֿלאָד־קערפּער קען ווערן איבערגעשפּילט. ענדערן די לייען־בופֿער־גרייס פֿון דער אַפּלאַקיישאַן קען איבערלאָזן די בקשה־פֿראַימינג פּונקט ווי זי איז געווען.

דער וועג איז וויכטיק פֿאַר יענער באַאַכטונג. קלאַרטעקסט־וועגשיקן בלייזט אַרויס די HTTP־פֿראַימינג פֿון דעם אַרויפֿלאָד צום פּראָקסי; געוויינטלעך end-to-end HTTPS לייגט זי אין אַ טונעל. HTTP/2 ניצט זײַן אייגענע פֿראַימינג. דערפֿאַר דערקלערן די היסטאָרישע באַגרענעצונגען פֿון Squid באַזונדערע פֿריִערדיקע דורכפֿאַלן, נישט קיין כּלל אַז יעדער איצטיקער פּראָקסי אָפּוואַרפֿט געשטראָמטע אַרויפֿלאָדן.