Czytanie wysyłania w kawałkach nie wymaga chunked HTTP
Oddziel ograniczone odczyty aplikacji od ramkowania komunikatów HTTP/1.1, gdy wysyłanie zachowuje się inaczej przez proxy przekazujące.
Nie. Klient może czytać duży plik w małych buforach i wysłać go ze znanym Content-Length. Ograniczone odczyty kontrolują zużycie pamięci; ramkowanie HTTP mówi odbiorcy, gdzie kończy się treść żądania.
Stabilny plik, którego długość w bajtach zna biblioteka HTTP, różni się od generatora wytwarzającego nieznaną ilość danych. Dla obu źródeł używaj interfejsu treści obsługiwanego przez bibliotekę. Nie trzeba składać całego pliku w łańcuch tylko po to, by podać długość.
W HTTP/1.1 sprawdź faktycznie wysyłane ramkowanie: Content-Length lub kodowanie transferu chunked zgodnie z regułami protokołu. Kodowanie chunked dodaje znaczniki rozmiaru poza zawartością pliku. Nie łącz sprzecznych pól ramkowania i nie zgaduj długości, by przekonać proxy do przyjęcia wysyłania.
Jeśli wysyłanie przez proxy się nie powiedzie, zapisz wersję HTTP, źródło treści i pierwsze odrzucenie. Odpowiedź 411 sugeruje inne dochodzenie niż połączenie zamykane w połowie treści. Jeśli zamiast tego zawodzą ponowienia uwierzytelniania, sprawdź, czy treść wysyłania można odtworzyć. Zmiana rozmiaru bufora odczytu aplikacji może pozostawić ramkowanie żądania dokładnie takie, jakie było.
Trasa ma znaczenie dla tej obserwacji. Przekazywanie zwykłym tekstem wystawia ramkowanie HTTP wysyłania na widok proxy; zwykły HTTPS od końca do końca umieszcza je w tunelu. HTTP/2 używa własnego ramkowania. Dlatego historyczne ograniczenia Squida wyjaśniają konkretne stare awarie, a nie regułę, że każde dzisiejsze proxy odrzuca wysyłanie strumieniowe.