Safari 파일 업로드가 0바이트라면? 서비스 워커 확인법

파일 크기와 서버 수신 크기를 나란히 본다

Safari에서 파일을 선택했는데 서버가 0바이트 요청을 받는다면, 용량 제한을 높이기 전에 서비스 워커가 현재 페이지를 제어하는지 확인할 필요가 있다. Safari Technology Preview 255는 디스크 기반 File을 이런 페이지에서 보낼 때 fetch와 XMLHttpRequest의 본문이 비는 회귀 오류를 수정했다고 밝혔다.

페이지의 제어 상태는 navigator.serviceWorker.controller로 읽는다. 서비스 워커를 등록한 적이 있는지와 지금 이 페이지가 제어받는지는 다른 질문이다. 다음 코드는 개발자 콘솔에서 현재 상태를 확인하는 예다.

console.log(navigator.serviceWorker?.controller?.scriptURL ?? null);

스크립트 URL이 나오면 현재 제어하는 서비스 워커가 있다는 뜻이다. 다만 이 값만으로 오류 원인이 확정되지는 않는다. 선택한 파일의 size, 파일을 읽은 결과, 서버의 실제 수신 바이트를 같은 요청에 연결해 보아야 한다.

서비스 워커가 없어도 파일 출처를 확인해야 한다

WebKit 319985번 버그의 최초 제보자는 파일 크기와 페이지 안의 읽기는 정상이지만 전송 본문이 비었다고 보고했다. 이후에는 서비스 워커 없이 IndexedDB에서 꺼낸 파일에서도 비슷한 증상이 제보됐다. 따라서 controller가 null이라는 이유만으로 이 계열의 파일 전송 문제를 배제할 수 없다.

실제 수정 커밋은 두 경로를 설명한다. 하나는 IndexedDB 저장소 안의 파일을 요청에 넣을 때 검사에 막히는 문제다. 다른 하나는 iOS 서비스 워커 프로세스에서 필요한 파일 읽기 권한을 전달하지 못하는 문제다. 버그 보고에는 fetch와 XHR 모두에서 빈 요청 본문이 발생한 사례가 있다.

같은 파일·엔드포인트에서 조건을 하나씩 바꾼다

진단할 때는 실패 요청을 기준으로 파일 출처와 서비스 워커 상태를 기록하고, 전송 전 읽기와 전송 후 수신을 분리한다. arrayBuffer()는 파일 내용을 바이너리 버퍼로 읽는다. 이 호출의 성공은 페이지가 내용을 읽었다는 뜻이며, 서버까지 전달됐다는 뜻은 아니다.

확인 항목	판단할 내용
파일 선택·드롭·IndexedDB 복원 중 어느 경로인가	같은 이름의 파일도 앱에 들어오는 경로를 구분한다.
현재 controller 값	서비스 워커 제어 여부를 기록한다.
file.size와 (await file.arrayBuffer()).byteLength	전송 전에 페이지에서 읽을 수 있는 크기를 확인한다.
서버가 받은 요청·파일 본문의 크기	파일 객체가 존재한다는 사실과 업로드 성공을 구분한다.

이 비교는 앱의 요청 형식을 유지한 테스트에서 해야 한다. multipart 요청 전체 크기에는 경계와 필드 정보도 포함되므로 파일 크기와 그대로 같아야 한다고 판단해서는 안 된다. 파일 파트의 수신 크기를 확인할 수 있다면 그 값을 따로 비교하는 편이 명확하다.

메모리 복사 우회는 작은 파일부터 검증한다

버그 제보자는 new Blob([await file.arrayBuffer()], { type: file.type })처럼 내용을 읽어 새 Blob으로 보내는 우회가 통했다고 밝혔다. 파일 전체를 메모리로 읽는 방식이므로 큰 파일에 그대로 확대 적용하기보다 앱이 다루는 크기와 요청 형식으로 시험할 필요가 있다.

프리뷰의 수정 여부를 비교할 때도 서버 수신 결과까지 확인해야 한다. STP 255는 macOS용 시험판이며, 이 릴리스 기록만으로 이용자의 iPhone이나 정식 Safari가 모두 수정됐다고 결론낼 수 없다. 운영 오류를 닫는 기준은 정상으로 보이는 파일 선택 화면이 아니라, 문제가 발생하던 환경에서 파일 내용이 끝까지 도착하는지다.