getContentLengthLong이 -1을 반환할 때 Java 프록시 다운로드

프록시를 통한 Java 다운로드에서 알 수 없는 Content-Length를 처리하되, 크기 메타데이터 부재를 빈 응답으로 취급하지 마십시오.

getContentLengthLong() == -1 은 사용 가능한 메타데이터에 알려진 콘텐츠 길이가 없다는 뜻입니다. 스트림 읽기를 계속하고 수신한 바이트 수나 불확정 진행률을 표시하십시오. 빈 응답으로 취급하거나 음수 크기의 버퍼를 할당해서는 안 됩니다.

long expected = connection.getContentLengthLong();
long received = 0;
byte[] buffer = new byte[8192];
try (InputStream input = connection.getInputStream()) {
    int count;
    while ((count = input.read(buffer)) != -1) {
        output.write(buffer, 0, count);
        received += count;
    }
}

연결은 이미 구성되어 있고 output 은 호출자가 소유합니다. 이 루프 주변에서 연결 및 읽기 타임아웃과 애플리케이션의 크기 제한을 유지하십시오. I/O 오류는 실패한 다운로드이며, 더 적은 바이트로 성공적으로 완료된 것이 아닙니다.

길이는 같은 계층에서 비교하십시오. HTTP/1.1의 chunked 인코딩은 Content-Length를 대체할 수 있으며 HTTP 구현이 이를 디코딩합니다. 프록시가 이를 다시 프레이밍할 수 있습니다. 압축 해제 때문에 애플리케이션의 디코딩된 바이트 수가 인코딩된 Content-Length와 달라질 수도 있습니다.

Transfer-Encoding과 Content-Length가 모두 나타나면 편리한 숫자를 고르지 마십시오. HTTP 프레이밍은 전송 인코딩에 우선권을 주며 그 조합을 가능한 오류로 취급합니다. 그 파싱은 준수하는 구현에 맡기십시오.

HTTP 게이트웨이를 통한 FTP URL은 구체적인 URLConnection 동작을 확인해야 합니다. 모든 JDK에서 모든 HTTP 헤더 접근자가 일반 HTTP URL과 같이 동작한다고 보장하지는 않습니다. 메타데이터가 중요한 곳에서는 long 값을 쓰는 length API를 사용하고, 완료된 산출물을 실제로 요구되는 길이나 체크섬에 대해 검증하십시오. 본문을 읽는다고 해서 이전에 없던 헤더가 나타나지는 않습니다.

관련 글