기술 · 실용 가이드
curl 재개 후 파일이 손상됐나요? 모든 범위를 강한 ETag에 묶으세요
바이트 오프셋은 표현의 정체성이 아닙니다. Range와 If-Range를 쓰고 정확한 206만 이어 붙이며, 200이면 처음부터 새로 쓰고 검증하세요.
안전한 재개에서는 이어 붙인 모든 바이트가 같은 HTTP 표현에 속해야 합니다. curl -C -가 쓰는 로컬 길이는 오프셋일 뿐 콘텐츠 정체성이 아닙니다.
부분 파일을 최종 URL과 강한 ETag에 묶고 Range와 If-Range로 나머지를 요청하세요. 206과 200에 따라 이어 쓰기와 전체 교체를 나누고 검증 후 원자적으로 승격하세요.
1. 로컬 길이는 정체성이 아니라 오프셋입니다
curl -C -는 대상 길이를 보고 나머지 바이트를 요청하지만 원격 객체가 같은 버전임을 증명하지 않습니다. 최종 URL, 강한 ETag, 로컬 길이, 예상 총길이와 배포자 다이제스트를 한 출력에 묶인 사이드카에 저장하세요.
전용 .part 파일을 쓰고 여러 URL이 한 ETag 상태 파일을 공유하지 않게 하세요.
2. 재개 전에 강한 검증자를 요구하세요
Range: bytes=N-와 저장한 강한 ETag의 If-Range를 보내세요. RFC 9110은 약한 ETag를 If-Range에 쓰지 못하게 합니다. 강한 검증자가 없으면 새 파일에 0바이트부터 다시 받으세요.
--etag-compare는 If-None-Match를 보내며 If-Range와 다릅니다. 래퍼는 If-Range를 명시하고 응답 헤더를 캡처해야 합니다.
3. 응답으로 쓰기 방식을 결정하세요
206이고 Content-Range가 N에서 시작하며 총길이와 검증자가 맞을 때만 이어 붙이세요. 먼저 임시 tail에 쓰고 헤더를 확인한 뒤 결합합니다.
If-Range 불일치의 200은 전체 응답이므로 새 임시 파일에 써야 하며 기존 부분에 붙이면 안 됩니다. 416은 길이, 총길이와 검증자를 조사할 신호입니다.
4. 전송 오류만 재시도하세요
분류된 일시적 전송 오류만 제한과 백오프로 재시도하세요. 인증 실패, 리디렉션 변경, 검증자 없음, 예상 밖 상태, 잘못된 Content-Range와 다이제스트 불일치는 중단 또는 깨끗한 재시작 조건입니다.
curl 8.5.0 실험에서 검증 없는 변경 객체는 206과 혼합 파일을 만들었고, 이전 ETag의 If-Range는 200 전체 교체를 만들었으며, 같은 객체는 206 결합 후 다이제스트가 일치했습니다.
5. 검증한 뒤 원자적으로 승격하세요
완료 뒤 배포자 다이제스트를 우선 확인하세요. 없으면 총길이와 같은 강한 ETag를 확인하되 길이만으로 무결성을 증명하지 못함을 인정하고 형식 검사도 실행하세요.
승인 후에만 같은 파일 시스템에서 원자적으로 이름을 바꾸세요. 사이드카와 로그를 남기고 혼합되거나 검증할 수 없는 부분 파일은 격리하세요.
