다운로드한 파일이 HTTP 상태 줄로 시작할 때

PDF나 스프레드시트라고 생각한 파일이 HTTP/1.1 200 OK 로 시작한다면, 다운로더가 파일 대신 원시 응답을 저장한 것입니다. 이 도식적 응답에는 내용이 네 바이트뿐입니다.

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

파일은 DATA 입니다. 상태 줄, 헤더, 크기 표시, 종료 구조는 HTTP에 속합니다. 헤더 길이가 일정하지 않으므로 고정된 바이트 수를 제거하는 것은 안전하지 않습니다. 첫 빈 줄 뒤의 모든 내용을 복사해도 청크 프레이밍이 남고, 정보 응답이 최종 응답보다 앞설 수 있습니다.

일반 다운로드에서는 원시 소켓에서 파일로 복사하는 대신 HTTP 클라이언트의 응답 본문 인터페이스를 사용하십시오. 프록시를 구성하고 최종 상태를 검증한 뒤 본문을 임시 출력으로 스트리밍하십시오. 메시지 프레이밍은 클라이언트가 처리합니다. 길이로 구분된 본문, 청크 본문, 연결로 구분된 본문은 각각 다른 파싱이 필요합니다.

콘텐츠 인코딩은 또 다른 계층입니다. 클라이언트의 문서화된 동작에 따라 디코딩된 파일 바이트가 필요한지, 명시적으로 요청한 원시 콘텐츠가 필요한지 결정하십시오. 압축된 바이트가 자동으로 프록시 손상을 뜻하지는 않습니다.

애플리케이션이 소켓 수준 코드를 유지해야 한다면, 그 모든 파싱 규칙과 읽기·쓰기 처리를 함께 책임집니다. 버퍼 용량이 아니라 읽기가 실제로 반환한 바이트 수만 기록하고, 부분 쓰기도 처리하십시오. 그렇지 않으면 오래된 버퍼 내용이 올바르게 추출된 본문조차 손상시킬 수 있습니다.

HTTPS는 CONNECT 응답을 벗겨내는 것보다 더 많은 것을 요구합니다. 터널이 성립한 뒤 목적지 TLS를 수립하고, 그다음 내부 HTTP 응답을 파싱하십시오. 프록시 헤더 뒤에 오는 암호화된 바이트는 다운로드할 파일이 아닙니다.

실패했거나 불완전한 출력은 임시 이름으로 남겨 두십시오. 전송과 파일 검증이 성공한 뒤에만 공개하십시오. 비어 있지 않은 파일이 완전한 다운로드를 증명하지는 않습니다.