15장 엔터티와 인코딩

http는 다음을 보장한다

• 객체의 올바른 식별
• 객체의 올바른 압축 해제
• 항상 최신인 객체
• 사용자의 요구
• 빠르고 효율적인 데이터 전송
• 조작되지 않음

이를 보장하기 위해서 http는 잘 라벨링된 엔터티를 사용한다.

15.1 메세지는 컨테이너, 엔터티는 화물

주요 엔터티 헤더 필드

• Content-Type
• Content-Length
• Content-Language
• Content-Encoding
• Content-Location
• Content-Range
• Content-MD5
• Last-Modified
• Expires
• Allow
• ETag
• Cache-Control

15.1.1 엔터티 본문

엔터티 본문은 가공되지 않은 날 데이터에 불과하다.
그래서 헤더에서 그 의미를 설명할 필요가 있다.

15.2 Content-Length: 엔터티의 길이

Content-Length 헤더는 엔터티 본문을 포함한 메세지에서는 필수적으로 있어야 한다.(청크 인코딩을 제외하면)

15.2.1 잘림 검출

커넥션이 정상적으로 닫힌 것인지 확인하려면 Content-Length가 필요하다.
메세지 잘림은 캐싱 프락시 서버에서 특히 취약하다.
프락시 서버는 명시적으로 Content-Length 헤더를 갖고 있지 않은 http 본문은 보통 캐시하지 않는다.

15.2.2 잘못된 Content-Length

Content-Length가 잘못된 값을 담고 있는 경우 큰 피해를 유발할 수 있다.

15.2.3 Content-Length와 지속 커넥션

Content-Length는 지속 커넥션을 위해 필수다.
예외는 청크 인코딩

15.2.4 콘텐츠 인코딩

공간을 절약할 수 있도록 본문을 인코딩한다.
인코딩할 경우 Content-Length 헤더는 원본의 길이가 아닌 인코딩된 본문의 길이를 바이트 단위로 정의한다.

15.2.5 엔터티 본문 길이 판별을 위한 규칙

끝나는 위치를 바르게 판별하는 규칙이며, 순서대로 적용되어야 한다.

1. 본문을 갖는 것이 허용되지 않는 http 메세지에서는 Content-Length헤더가 무시된다.

2. 메세지가 Transfer-Encoding(청크 인코딩 헤더)를 포함할 경우 '0바이트 청크'라는 특별한 패턴으로 끝나야 한다. 이 헤더가 있을 경우 Content-Length헤더를 무시해야 한다.

3. Content-Length 헤더를 갖고 Transfer-Encoding 헤더가 없다면 Content-Length헤더는 본문의 길이를 담게 된다.

4. 'multipart/byteranges' 미디터 타입을 사용하고 엔터티 길이가 정의되지 않았다면, 메세지의 각 부분은 각자가 스스로의 크기를 정의할 것이다.

5. 위의 규칙에 해당 사항이 없을 경우, 서버만이 메세지가 끝났음을 알리기 위해서 커넥션을 닫을 수 있다.

15.3 엔터티 요약

여러가지 이유로 메세지의 일부분이 전송 중에 변형되는 일이 일어난다.
이러한 변경을 감지하기 위해서 체크섬을 이용한다.
Content-MD5 헤더는 엔터티 본문에 적용한 MD5 알고리즘에 대한 결과를 보여준다. 이를 통해 무결성을 검증한다.

15.4 미디어 타입과 차tpt

Content-Type 헤더 필드는 엔터티 본문의 MIME 타입을 기술한다.
인코딩 전 후의 값이 같다

15.5 콘텐츠 인코딩

http 어플리케이션은 콘텐츠를 보내기 전에 인코딩을 하려고 한다.

15.5.1 콘텐츠 인코딩 과정

1. 서버가 Content-Type, Content-Length 헤더를 수반한 원본 응답 메세를 생성
2. 콘텐츠 인코딩 서버가 인코딩된 메세지를 생성
3. 수신 측은 인코딩된 메세지를 받아 디코딩하고 원본을 획득

15.5.3 Accept-Encoding gpej

클라이언트는 자신이 지원하는 인코딩의 목록을 Accept-Encoding 헤더를 통해 전달한다. 또한 Q 값을 매개변수로 선호도를 전달할 수 있다.

15.6 전송 인코딩와 청크 인코딩

15.6.1 안전한 전송

• 알 수 없는 크기
  : 콘텐츠 인코더는 메세지 본문의 최종 크기를 판단할 수 없다. 그리고 그 사이즈를 알기 전에 데이터의 전송을 시작하려고 한다.

15.6.2 Transfer-Encoding 헤더

• Transfer-Encoding
  : 어떤 인코딩이 메세지에 적용되었는지 수신자에게 알려준다
• TE
  : 어떤 확장된 전송 인코딩을 사용할 수 있는지 서버에게 알려주기 위해 요청 헤더에 사용한다.

15.6.3 청크 인코딩

청크 인코딩은 메세지를 청크 여럿으로 쪼갠다.
이를 사용하면 메세지를 보내기 전에 전체 크기를 알 필요가 없어진다.
청크 인코딩은 콘텐츠의 동적 생성에 대한 해결책이다. 서버는 크기가 0인 청크로 본문이 끝났음을 알려주므로써, 보내기 전 본문의 길이를 알 수 없는 동적 생성에 대한 딜레마를 해결해준다.

15.6.4 콘텐츠와 전송 인코딩의 조합

콘텐츠 인코딩과 전송 인코딩은 동시에 사용될 수 있다.

15.6.5 전송 인코딩 규칙

전송 인코딩이 적용될 때, 필요한 규칙들이 있다.

• 전송 인코딩의 집합은 반드시 'chunked'를 포함해야 한다. 예외는 메세지가 커넥션의 종료로 끝날 때
• 청크 전송 인코딩이 사용되었다면, 마지막 전송 인코딩이 존재해야 한다.
• 청크 전송 인코딩은 반드시 메세지 본문에 한 번 이상 적용되어야 한다.

위의 규칙으로 수신자는 메세지의 전송 길이를 알 수 있다.

15.7 시간에 따라 바뀌는 인스턴스

같은 URL 은 시간에 따라 다른 버전의 객체(버전, 인스턴스)를 가리킬 수 있다.

인스턴스 조작 = http 프로토콜이 어떤 특정한 종류의 요청이나 응답을 다루는 방법. 범위 요청과 델타 인코딩이 있다.

15.8 검사기와 신선도

조건부 요청을 통해 클라이언트가 서버에게 자신이 갖고 있는 버전을 말해주고, 검사기를 통해 이 인스턴스가 신선한 지 판별한다.

15.8.1 신선도

서버는 Expires나 Cashe-Control 헤더를 통해 콘텐츠가 신선한 지 정보를 제공할 수 있다.

15.8.2 조건부 요청과 검사기

시간 기준 = If-Modified(Unmodified)-Since : Last-Modified 검사기를 사용한다. 약한 검사기 이다.

엔터티 테그 비교 = If-(None)Match : ETag 검사기 사용. 강한 검사기 이다.

태그 앞에 'W/'를 붙임으로써 약한 엔터티 태그임을 알릴 수도 있다.

15.9 범위 요청

클라이언트는 문서의 일부분이나 특정 범위만 요청할 수 있다.
Range 헤더를 통해 요청할 수 있다.
Accept-Ranges 헤더를 통해 서버는 클라이언트에게 자신이 범위를 받아들일 수 있는지 알려줄 수 있다.

15.10 델타 인코딩

부분 인코딩이다.
변경된 부분만을 보내서 인스턴스 조작을 할 수 있다.
ETag 를 통해 버전을 비교하고, 버전이 다르다면
클라이언트는 A-IM헤더를 통해 델타 인코딩을 받아들일 수 있음을 알려준다.
서버는 새로운 ETag를 보내 갱신시키고, Delta-base를 통해 사용된 기저 문서의 ETag를 보내준다.