HTTP의 Content-Length → 엔터티의 길이

Content-Length: 엔터티의 길이

• Content-Length 헤더는 메시지의 엔터티 본문의 크기를 바이트 단위
• 어떻게 인코딩 되었든 상관없이 크기를 표현
• Content-Length 헤더는 메시지를 청크 인코딩으로 전송하지 않는 이상, 엔터티 본문을 포함한 메시지에서는 필수적으로 있어야 함
• 서버 충돌로 인한 메시지 잘림 검출과 지속 커넥션을 공유하는 메시지를 분할하고자 할 때 필요

1. 잘림 검출

• 오래된 버전의 HTTP는 커넥션이 닫힌 것을 보고 메시지가 끝났음을 인지
• Content-Length가 없다면 커넥션이 정상적으로 닫힌 것인지 구분하지 못함
• 메시지 잘림은 캐싱 프록시 서버에서 특히 취약
• 캐시가 잘린 메시지를 수신했으나 잘렸다는 것을 인삭하지 못했다면, 캐시는 결함이 있는 컨텐츠를 저장하고 계속해서 제공.
• 결함있는 컨텐츠를 제공하는 것을 방지하기 위하여, 캐싱 프록시 서버는 명시적으로 Content-Length 헤더를 갖고 있지 않은 HTTP 본문은 캐시하지 않음

2. 잘못된 Content-Length

• Content-Length가 잘못된 값을 담고 있을 경우 아예 빠진 것보다도 큰 피해를 유발함
• HTTP/1.1에서는 사용자 에이전트가 잘못된 길이를 받고 이를 인지했을 때, 사용자에게 알려주게 됨

3. Content-Length와 지속커넥션

• Content-Length는 지속 커넥션을 위해 필수
• 클라이언트에게 메시지 하나가 어디서 끝나고, 다음 시작은 어디인지 알려줌
• 커넥션은 지속적이기에, 클라이언트가 커넥션이 닫힌 위치를 근거로 메시지의 끝을 인식하는 것은 불가능
• HTTP 애플리케이션은 엔터티 본문의 길이와 끝을 인식하고자 Content-Length 헤더를 활용
• 청크 인코딩을 사용하는 경우는 예외
• 청크 인코딩은 데이터를 특정 크기를 갖는 청크들로 쪼개어 보내며, Content-Legnth 헤더를 필요로 하지 않음
  
  
  

컨텐츠 인코딩

• HTTP는 보안을 강화하거나 압축을 통해 공간을 절약할 수 있도록, 엔터티 본문을 인코딩할 수 있게 해줌
• 만약 본문의 컨텐츠가 인코딩되어 있다면, Content-Length 헤더는 원본이 아닌 인코딩된 본문을 바이트 단위로 정의함
• HTTP/1.1 명세에서 어떤 헤더도 인코딩 전 원본의 길이를 보내고자 사용되지 않음
• 클라이언트가 수행한 디코딩 과정의 검증을 어려움
• Content-MD5 헤더도 인코딩된 문서의 MD5를 담음 → 자주 사용 X