Content-Length 숫자는 글자 수일까 바이트 수일까

Content-Length는 눈에 보이는 글자 수가 아닌 바이트 길이입니다

Content-Length는 수신자에게 보내는 메시지 본문의 크기를 바이트로 나타냅니다. 한글과 이모지가 섞인 문서의 글자 수를 그대로 적으면 맞지 않을 수 있습니다. 또 전체 크기를 미리 알 수 없는 스트리밍 응답처럼 이 헤더 없이 본문을 보내는 경우도 있어 누락을0바이트로 해석하지 않습니다. 근거: MDN Content-Length, 2026-11-04.

근거: MDN Content-Length · 2026-11-04 확인

헤더·본문·표시 길이를 별도로 비교합니다

가상의 텍스트 파일에서 편집기의 문자 수, UTF-8로 저장한 바이트 수, HTTP로 압축해 보낸 본문 크기는 서로 다른 측정 대상입니다. 동일하다고 가정해 수치를 옮기지 않습니다. 프로토콜 전체 패킷이나 헤더 크기까지 Content-Length에 포함한 것으로 읽지도 않습니다. 이 예는 단위 구분을 위한 것이며 실제 파일이나 네트워크에서 바이트 수를 계산한 결과가 아닙니다.

근거: MDN Content-Length · 2026-11-04 확인

직접 응답을 만든다면 실제 전송 바이트를 기준으로 합니다

서버 프레임워크가 길이를 관리한다면 문서의 규칙을 따르고 문자열 길이로 헤더를 임의 덮어쓰지 않습니다. 직접 계산해야 하는 환경은 최종 인코딩·압축 등 적용 뒤 전송할 본문의 길이와 일치시켜야 합니다. 동적으로 스트리밍하면서 전체 길이를 모른다면 그 환경의 전송 방식을 사용합니다. 이 글은 서버 구현을 제공하거나 길이 오류를 수정한 사례가 아닙니다.

근거: MDN Content-Length · 2026-11-04 확인

다운로드가 잘리면 길이와 전송 결과를 순서대로 확인합니다

허가된 자원에서 상태·인코딩·길이 헤더를 기록하고 도구가 보여 준 크기가 압축된 전송량인지 복원된 크기인지 확인합니다. 실제 수신이 중단되었는지와 파일이 해당 형식으로 열리는지도 봅니다. 길이 불일치처럼 보여도 서로 다른 단계의 크기를 비교했다면 먼저 기준을 맞춥니다. 재현이 필요할 때는 작은 테스트 파일로 하고 반복 대용량 다운로드는 피합니다.

헤더가 없을 때와 잘못된 값이 있을 때를 나눕니다

HTTP 버전과 전송 방식에 따라 길이를 다른 구조에서 알 수 있으므로 헤더 없음 자체는 실패 판정이 아닙니다. 반면 잘못된 길이 선언은 메시지 처리 문제를 만들 수 있어 운영 응답에서 직접 시험하기보다 담당자에게 관찰 자료를 전달합니다. 성공은 본문을 정상 수신·해독하고 요구한 내용까지 확인한 결과로 적습니다.

옆 문서로 이어가기