Читање отпремања у деловима не захтева chunked HTTP
Раздвојите ограничена читања апликације од оквира поруке HTTP/1.1 када се отпремање понаша другачије кроз forward proxy.
Не. Клијент може да чита велики фајл у малим баферима и пошаље га са познатим Content-Length. Ограничена читања контролишу потрошњу меморије; HTTP оквир говори примаоцу где се тело захтева завршава.
Стабилан фајл чију дужину у бајтовима HTTP библиотека зна разликује се од генератора који производи непознату количину података. Користите интерфејс тела који библиотека подржава за оба извора. Не морате да састављате цео фајл у стринг само да бисте навели дужину.
За HTTP/1.1, прегледајте оквир који је заиста послат: Content-Length или chunked transfer coding према правилима протокола. Chunked кодирање додаје ознаке величине изван садржаја фајла. Не комбинујте противречна поља оквира и не погађајте дужину да бисте убедили proxy да прихвати отпремање.
Ако отпремање кроз proxy не успе, забележите HTTP верзију, извор тела и прво одбијање. Одговор 411 упућује на другачију истрагу од везе која се затвара на пола тела. Ако уместо тога не успевају поновни покушаји аутентификације, проверите да ли тело отпремања може поново да се репродукује. Промена величине бафера за читање у апликацији може оставити оквир захтева потпуно истим.
Путања је важна за то запажање. Преусмеравање у чистом тексту излаже HTTP оквир отпремања proxy-ју; обичан HTTPS од краја до краја ставља га унутар тунела. HTTP/2 користи сопствени оквир. Историјска ограничења Squid-а зато објашњавају одређене старе неуспехе, а не правило да сваки данашњи proxy одбија стримована отпремања.