Leggere l'upload a blocchi non richiede HTTP chunked
Separare le letture applicative delimitate dall'incorniciatura dei messaggi HTTP/1.1 quando un upload si comporta diversamente attraverso un proxy diretto.
No. Un client può leggere un file grande in buffer piccoli e inviarlo con un Content-Length noto. Le letture delimitate controllano l'uso della memoria; l'incorniciatura HTTP dice al destinatario dove termina il corpo della richiesta.
Un file stabile di cui la libreria HTTP conosce la lunghezza in byte è diverso da un generatore che produce una quantità sconosciuta di dati. Usare l'interfaccia del corpo supportata dalla libreria per entrambe le sorgenti. Non serve assemblare l'intero file in una stringa solo per fornire una lunghezza.
Per HTTP/1.1, esaminare l'incorniciatura effettivamente inviata: Content-Length o codifica di trasferimento chunked secondo le regole del protocollo. La codifica chunked aggiunge indicatori di dimensione all'esterno del contenuto del file. Non combinare campi di incorniciatura contraddittori e non indovinare una lunghezza per convincere un proxy ad accettare l'upload.
Se un upload attraverso un proxy fallisce, annotare la versione HTTP, la sorgente del corpo e il primo rifiuto. Una risposta 411 suggerisce un'indagine diversa da una connessione che si chiude a metà corpo. Se invece falliscono i tentativi di autenticazione, verificare se il corpo dell'upload può essere riprodotto. Cambiare la dimensione del buffer di lettura dell'applicazione può lasciare l'incorniciatura della richiesta esattamente com'era.
Il percorso conta per quell'osservazione. L'inoltro in chiaro espone l'incorniciatura HTTP dell'upload al proxy; un normale HTTPS end-to-end la mette dentro un tunnel. HTTP/2 usa la propria incorniciatura. Quindi i limiti storici di Squid spiegano specifici guasti antichi, non una regola per cui ogni proxy attuale rifiuti gli upload in streaming.