기술 · 실용 가이드
curl 오류 18? 재시도·재개 전에 누락 바이트를 증명하세요
CURLE_PARTIAL_FILE은 실제 전송 크기가 상대가 먼저 알린 크기와 달랐다는 뜻입니다. 부분 파일, 응답 헤더, 추적을 보존하고 프레이밍·프로토콜·중간 경로를 분리한 뒤 새 전송 또는 검증자 기반 재개를 선택하세요.
curl 오류 18은 전송 크기 불일치의 증거이지 하나의 네트워크 원인을 확정하는 진단명이 아닙니다. curl 프로젝트는 CURLE_PARTIAL_FILE을 미리 보고된 크기보다 짧거나 긴 전송으로 정의합니다.
첫 부분 파일을 덮어쓰거나 자동 재시도를 켜지 마세요. 응답 프레이밍, 수신 바이트, 표현의 정체성을 기록한 뒤 서버, 프록시, 프로토콜, 클라이언트 경로를 하나씩 시험합니다.
1. 첫 실패 증거를 고정하세요
부분 출력을 고유한 증거 파일로 옮기고 바이트 수와 해시를 기록합니다. curl 버전과 기능, 비밀을 제거한 명령, 시작·종료 시각, 종료 코드, URL, 프록시 경로, 래퍼나 CI 사용 여부도 저장합니다.
새 출력으로 한 번만 증거를 수집하고 응답 헤더와 시간 표시 추적을 따로 보관합니다. Authorization, Cookie, 서명 쿼리, 인증서는 반드시 가립니다.
2. 네트워크보다 프레이밍을 먼저 읽으세요
HTTP/1.1의 최종 Transfer-Encoding이 chunked라면 0 크기 종료 청크가 필요합니다. Transfer-Encoding이 없고 Content-Length가 유효하면 그 값이 기대 본문 바이트 수이며, 도달 전 연결 종료는 RFC 9112상 불완전합니다.
gzip·br는 콘텐츠 인코딩이고 chunked는 전송 프레이밍입니다. Accept-Encoding이나 HTTP 버전 변경은 분기를 비교할 수 있지만 잘못된 길이, 원본 프로세스 중단, 중간 장비 고장을 자체 해결하지 않습니다.
3. 한 번에 경계 하나만 바꾸세요
매번 새 출력에 기록하면서 원본 직결과 CDN, IPv4와 IPv6, HTTP/1.1과 HTTP/2·3, 압축과 identity 중 하나만 바꿉니다. 상태, 최종 URL, 프로토콜, 선언 길이, 수신량, 종료 코드, 해시를 남깁니다.
한 경로의 성공은 다른 경로의 안전을 증명하지 않습니다. 원본은 성공하고 프록시만 잘린다면 두 추적을 보존하고, 모두 같은 바이트에서 멈추면 앱, 상류 시간 제한, Content-Length 생성, 저장소 읽기를 점검합니다.
4. 부분 바이트를 사용할 수 있는지 결정하세요
200 상태만으로 승인하지 마세요. curl 종료 0, 프레이밍 또는 기대 바이트 완료, 게시자 체크섬·서명·압축 검사·응용 파서 같은 무결성 신호가 모두 필요합니다.
API는 부작용도 확인합니다. 비멱등 POST는 서버에서 처리된 뒤 응답만 잘릴 수 있습니다. 재전송 전에 멱등 키, 거래 ID 또는 상태 API를 확인하세요.
5. 계약이 증명될 때만 재개하세요
서버가 필요한 byte range를 지원하고 ETag 또는 Last-Modified로 같은 표현임을 확인할 때만 재개합니다. 예상 부분 상태와 범위가 오는지도 확인합니다.
검증자가 없거나 약하거나 바뀌면 새 대상에서 다시 시작하고 맹목적으로 이어 쓰지 마세요. 종료 코드, 프레이밍, 바이트 수, 무결성이 통과하고 실패 경로도 수정 또는 제외되어야 종료입니다.
