Читання завантаження частинами не потребує chunked HTTP
Відокремте обмежені читання застосунку від фреймінгу повідомлень HTTP/1.1, коли завантаження поводиться інакше через forward proxy.
Ні. Клієнт може читати великий файл невеликими буферами й надсилати його з відомим Content-Length. Обмежені читання контролюють використання пам'яті; фреймінг HTTP повідомляє одержувачу, де закінчується тіло запиту.
Стабільний файл, байтову довжину якого знає бібліотека HTTP, відрізняється від генератора, що створює невідому кількість даних. Використовуйте підтримуваний бібліотекою інтерфейс тіла для обох джерел. Вам не потрібно збирати весь файл у рядок лише для того, щоб указати довжину.
Для HTTP/1.1 перевірте фреймінг, який справді надіслано: Content-Length або chunked transfer coding за правилами протоколу. Chunked-кодування додає маркери розміру поза вмістом файлу. Не поєднуйте суперечливі поля фреймінгу й не вгадуйте довжину, щоб переконати проксі прийняти завантаження.
Якщо завантаження через проксі не вдалося, зафіксуйте версію HTTP, джерело тіла й першу відмову. Відповідь 411 підказує інше дослідження, ніж з'єднання, що закривається посеред тіла. Якщо натомість не вдаються повторні спроби автентифікації, перевірте чи можна відтворити тіло завантаження. Зміна розміру буфера читання застосунку може залишити фреймінг запиту точно таким, як був.
Маршрут важливий для цього спостереження. Передавання відкритим текстом відкриває фреймінг HTTP завантаження проксі; звичайний наскрізний HTTPS поміщає його всередину тунелю. HTTP/2 використовує власний фреймінг. Тож історичні обмеження Squid пояснюють окремі давні збої, а не правило, що кожен сучасний проксі відхиляє потокові завантаження.