Citirea încărcării în bucăți nu necesită HTTP chunked
Separați citirile limitate ale aplicației de încadrarea mesajelor HTTP/1.1 atunci când o încărcare se comportă diferit printr-un proxy de redirecționare.
Nu. Un client poate citi un fișier mare în buffere mici și îl poate trimite cu un Content-Length cunoscut. Citirile limitate controlează consumul de memorie; încadrarea HTTP îi spune destinatarului unde se termină corpul cererii.
Un fișier stabil a cărui lungime în octeți este cunoscută de biblioteca HTTP diferă de un generator care produce o cantitate necunoscută de date. Folosiți interfața de corp acceptată de bibliotecă pentru ambele surse. Nu este nevoie să asamblați întregul fișier într-un șir doar pentru a furniza o lungime.
Pentru HTTP/1.1, inspectați încadrarea trimisă efectiv: Content-Length sau codificare de transfer chunked conform regulilor protocolului. Codificarea chunked adaugă markeri de dimensiune în afara conținutului fișierului. Nu combinați câmpuri de încadrare contradictorii și nu ghiciți o lungime pentru a convinge un proxy să accepte încărcarea.
Dacă o încărcare printr-un proxy eșuează, notați versiunea HTTP, sursa corpului și primul refuz. Un răspuns 411 sugerează o altă investigație decât o conexiune care se închide la mijlocul unui corp. Dacă în schimb eșuează reîncercările de autentificare, verificați dacă corpul încărcării poate fi redat din nou. Modificarea dimensiunii bufferului de citire al aplicației poate lăsa încadrarea cererii exact așa cum era.
Ruta contează pentru acea observație. Transferul în text clar expune încadrarea HTTP a încărcării către proxy; HTTPS obișnuit de la capăt la capăt o plasează într-un tunel. HTTP/2 folosește propria încadrare. Prin urmare, limitările istorice ale Squid explică anumite eșecuri vechi, nu o regulă că fiecare proxy actual respinge încărcările în flux.