15. 엔터티와 인코딩

15. 엔터티와 인코딩

HTTP가 보장하는 것

• 객체가 올바르게 식별 된다(Content-type, Content-Language 헤더)
• 객체가 올바르게 압축이 풀린다 (Content-Length, Content-Encoding 헤더)
• 객체는 항상 최신이다(엔터티 검사기와 캐시 만료 제어)
• 사용자의 요구를 만족할 것이다(Accept 관련 헤더들에 기반)
• 네트워크 사이를 빠르고 효율적으로 이동할 것이다(범위 요청, 델타 인코딩, 데이터 압축등)
• 조작되지 않고 온전하게 도착할 것이다(전송 인코딩 헤더, Content-MD5 체크섬)

엔터티 본문

• 가공되지 않은 데이터만을 담고 있다
• 엔터티 헤더를 이용해서 그 데이터의 의미를 설명해야 한다.

Content-Length

• 메시지의 엔터티 본문의 크기를 바이트 단위로 나타낸다
• 어떻게 인코딩 되었든 상관없이 크기를 표현한다(압축 되었으면 압축된 크기)
• 청크 인코딩으로 전송하지 않는 이상 필수적으로 있어야 한다
• 메시지가 잘렸는지 감시, 지속 커넥션을 공유하는 메시지를 올바르게 분할하고자 할 때 필요하다
• HEAD 응답에서는 무의미한 정보다
• Transfer-Encoding 헤더 필드를 갖고 있는 메시지라면 무시해야 한다.

엔터티 요약

• 엔터티 본문 데이터에 의한 의도치 않는 변경을 감지하기 위해 체크섬을 생성해서 이용할 수 있다.
• 악의적인 공격에는 의미가 없고, 의도치 않은 변경에 유효하다
• Content-MD5 헤더를 이용한다

Content-Type

• 엔터티 본문의 MIME 타입을 기술한다.
• 본문이 인코딩 되었더라도 인코딩 되기 전의 타입을 명시한다

Content-Encoding

• 콘텐츠를 인코딩 한 플래그를 나타낸다
• ex) Content-Encoding : gzip

Accept-Encoding

• 클라이언트가 자신이 지원하는 인코딩의 목록을 이 요청 헤더를 통해 전송한다.
• 요청에 이 헤더를 포함하지 않으면 어떠한 인코딩도 받아들일 수 있는 것으로 간주한다
• 각 인코딩에 q 값을 넣어 선호도를 나타낼 수 있다(0~1)

전송 인코딩

• Transfer-encoding 헤더로 전송 인코딩이 된 여부를 알 수 있다.
• 콘텐츠 인코딩은 콘텐츠 부분만 인코딩 하는 반면에 전송 인코딩은 메시지 전체를 인코딩 한다.
• TE 헤더를 통해 어떠한 확장된 전송 인코딩을 클라이언트가 사용할 수 있는지 표시한다

청크 인코딩

• 메시지를 일정 크기의 청크 여럿으로 쪼개고 각 청크를 순차적으로 보낸다
• 0바이트인 청크를 보냄으로서 본문의 끝을 알린다
• Content-Length 헤더를 만들 필요가 없으므로 동적으로 생성되는 본문에 유리하다
• 콘텐츠 인코딩과 혼합해서 사용할 수 있다.

If-Modified-Since

• 캐시가 만료되었을 때 사본이 변경되었는지 확인하는 특수한 요청
• 조건이 참이 아니라면 서버는 에러코드를 반환한다.

범위 요청

• 클라이언트가 문서의 일부분이나 특정 범위만 요청할 수 있도록 해주는 요청
• Range 헤더를 이용해서 특정 부분 이후부터 요청할 수 있다.
• 다운로드가 중간에 실패했을 때 다시 요청하는 경우에 유용하다

델타 인코딩

• 객체 전체가 아닌 변경된 부분에 대해서만 통신하여 전송량을 최적화하는 HTTP 프로토콜의 확장
• 일종의 인스턴스 조작
• A-IM : 어떠한 델타 인코딩 응답을 받을 수 있는지 나타내는 요청헤더
• IM : 사용한 델타 인코딩 종류를 나타내는 응답 헤더
• Delta-Base : 델타 인코딩을 사용한 베이스가 되는 ETag
• 델타 인코딩은 페이지가 변경되는 매 순간의 사본을 유지해야하므로 이득이 크지 않을 수 있다.