Om die oplaai in stukke te lees vereis nie chunked HTTP nie
Skei begrensde toepassingslees van HTTP/1.1-boodskapraamwerk wanneer 'n oplaai anders deur 'n vloedproxy optree.
Nee. 'n Kliënt kan 'n groot lêer in klein buffers lees en dit met 'n bekende Content-Length stuur. Begrensde lees beheer geheuegebruik; HTTP-raamwerk vertel die ontvanger waar die versoekliggaam eindig.
'n Stabiele lêer waarvan die HTTP-biblioteek die greptelengte ken, verskil van 'n generator wat 'n onbekende hoeveelheid data lewer. Gebruik die biblioteek se ondersteunde liggaamkoppelvlak vir albei bronne. Jy hoef nie die hele lêer in 'n string saam te stel net om 'n lengte te verskaf nie.
Vir HTTP/1.1, ondersoek die raamwerk wat werklik gestuur word: Content-Length of chunked-oordragkodering volgens die protokol se reëls. Chunked-kodering voeg grootte- merkers buite die lêerinhoud by. Moenie teenstrydige raamwerkvelde kombineer of 'n lengte raai om 'n proxy te oorreed om die oplaai te aanvaar nie.
As 'n oplaai deur 'n proxy misluk, teken die HTTP-weergawe, liggaambron en eerste weiering aan. 'n 411-antwoord dui op 'n ander ondersoek as 'n verbinding wat halfpad deur 'n liggaam sluit. As magtigingsherprobeer eerder misluk, kyk of die oplaailiggaam herspeel kan word. Om die toepassing se leesbuffer-grootte te verander, kan die versoekraamwerk presies laat soos dit was.
Die roete maak saak vir daardie waarneming. Gewone teks-deurstuur stel die oplaai se HTTP-raamwerk aan die proxy bloot; gewone end-tot-end HTTPS plaas dit binne 'n tonnel. HTTP/2 gebruik sy eie raamwerk. Historiese Squid-beperkings verduidelik dus spesifieke ou mislukkings, nie 'n reël dat elke huidige proxy gestroomde oplaais verwerp nie.