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