업로드를 청크로 읽는 데 chunked HTTP가 필요하지 않습니다

아니요. 클라이언트는 큰 파일을 작은 버퍼로 읽고 알려진 Content-Length와 함께 보낼 수 있습니다. 제한된 읽기는 메모리 사용을 제어하고, HTTP 프레이밍은 요청 본문이 어디서 끝나는지 수신자에게 알려 줍니다.

HTTP 라이브러리가 바이트 길이를 아는 안정적인 파일은 알 수 없는 양의 데이터를 생성하는 제너레이터와 다릅니다. 두 입력 모두 라이브러리가 지원하는 본문 인터페이스를 사용하세요. 길이를 제공하기 위해 파일 전체를 문자열로 조립할 필요는 없습니다.

HTTP/1.1에서는 실제로 전송되는 프레이밍을 확인하세요. 프로토콜 규칙에 따른 Content-Length 또는 chunked 전송 코딩입니다. chunked 코딩은 파일 내용 바깥에 크기 표시를 추가합니다. 모순되는 프레이밍 필드를 결합하거나 프록시가 업로드를 받아들이게 하려고 길이를 추측하지 마세요.

프록시를 거친 업로드가 실패하면 HTTP 버전, 본문 출처, 첫 번째 거부를 기록하세요. 411 응답은 본문 중간에 연결이 닫히는 경우와 다른 조사를 시사합니다. 대신 인증 재시도가 실패하면 업로드 본문을 다시 재생할 수 있는지 확인하세요. 애플리케이션의 읽기 버퍼 크기를 바꾸어도 요청 프레이밍은 그대로일 수 있습니다.

그 관찰에는 경로가 중요합니다. 평문 전달은 업로드의 HTTP 프레이밍을 프록시에 드러내고, 일반적인 종단 간 HTTPS는 이를 터널 안에 둡니다. HTTP/2는 자체 프레이밍을 사용합니다. 따라서 Squid의 역사적 제한은 특정한 옛 실패를 설명할 뿐, 오늘날 모든 프록시가 스트리밍 업로드를 거부한다는 규칙은 아닙니다.