Чтение загрузки по частям не требует chunked HTTP
Отделите ограниченные чтения приложения от кадрирования сообщений HTTP/1.1, когда загрузка ведёт себя иначе через пересылающий прокси.
Нет. Клиент может читать большой файл небольшими буферами и отправлять его с известным Content-Length. Ограниченные чтения контролируют расход памяти; кадрирование HTTP сообщает получателю, где заканчивается тело запроса.
Стабильный файл, длину которого в байтах знает HTTP-библиотека, отличается от генератора, создающего неизвестный объём данных. Для обоих источников используйте поддерживаемый библиотекой интерфейс тела. Не нужно собирать весь файл в строку только ради указания длины.
Для HTTP/1.1 проверьте фактически отправляемое кадрирование: Content-Length или chunked-кодирование передачи по правилам протокола. Chunked-кодирование добавляет маркеры размера вне содержимого файла. Не объединяйте противоречивые поля кадрирования и не угадывайте длину, чтобы убедить прокси принять загрузку.
Если загрузка через прокси не удалась, запишите версию HTTP, источник тела и первый отказ. Ответ 411 указывает на иное расследование, чем соединение, закрывающееся посреди тела. Если вместо этого не удаются повторные попытки аутентификации, проверьте, можно ли воспроизвести тело загрузки. Изменение размера буфера чтения приложения может оставить кадрирование запроса точно таким, каким оно было.
Маршрут важен для этого наблюдения. Передача открытым текстом раскрывает кадрирование HTTP загрузки прокси; обычный сквозной HTTPS помещает его в туннель. HTTP/2 использует собственное кадрирование. Поэтому исторические ограничения Squid объясняют отдельные старые сбои, а не правило, будто каждый современный прокси отвергает потоковые загрузки.