15. Entities and Encodings

01) 메시지는 컨테이너, 엔터티는 화물

메시지 엔터티는, 엔터티헤더와 엔터티 본문으로 이루어진다.

HTTP 메시지를 인터넷 운송 시스템의 컨테이너라고 생각한다면, (회색테두리)
HTTP 엔터티는 메시지의 실질적인 화물이다. (검정색 점선)

HTTP 엔터티 헤더는 HTTP 메시지의 내용물을 설명한다.

  **주요 엔터티 헤더 필드 10가지(HTTP/1.1)**
  - Content-Type: 엔터티에 의해 전달된 객체의 종류
  - Content-Length: 전달되는 메세지의 길이나 크기
  - Content-Language: 전달되는 객체와 가장 잘 대응되는 자연어
  - Content-Encoding: 객체 데이터에 대해 행해진 변형(압축 등)
  - Content-Location: 요청시점을 기준으로 객체의 또 다른 위치
  - Content-Range: 만약 이 엔터티가 부분 엔터티라면, 이 엔터티가 전체에서 어느부분에 해당하는지 정의
  - Content-MD5: 엔터티 본문의 콘텐츠에 대한 체크섬
  - Last-Modified: 서버에서 이 콘텐츠가 생성 혹은 수정된날.
  - Expires: 엔터티가 더이상 신선하지 않은 것으로 간주되기 시작한 날짜와 시각
  - Allow: 이 리소스에 대해 어떤 요청 메서드가 허용되는지

① 엔터티 본문

엔터티 본문은 가공되지 않은 날(raw) 데이터만을 담고 있다.
다른 정보들은 모두 헤더에 담겨있다.
엔터티 본문은 가공되지 않은 데이터에 불과하므로, 엔터티 헤더는 데이터의 의미에 대해 설명할 필요가 있다.
- 예시
  - Content-Type: 데이터를 어떻게 해석해야하는지
  - Content-Encoding: 데이터 압축 혹은 추가적인 인코딩이 되었는지 알려준다.
엔터티 본문은 콘텐츠가 텍스트, 바이너리, 이미지, 압축 유무, 영어, 일어에 상관없이 항상 CRLF 바로 다음에 위치한다.

02) Content-Length: 엔터티의 길이

메세지 엔터티 본문의 크기를 바이트 단위로 나타낸다.
어떻게 인코딩 되었는 상관없이 크기를 표현할 수 있다. (gzip으로 압축된 파일은 압축 후 크기)
Content-Length 헤더는 메시지를 청크 인코딩으로 전송하지 않는 이상 엔터티 본문을 포함한 메시지에서는 필수로 있어야한다.
Content-Length는 서버 충돌로 인해 메시지가 잘렸는지 감지하고자 할 때와
지속 커넥션을 공유하는 메시지를 올바르게 분할하고자 할 때 필요하다.

① 잘림 검출

옛날버전의 HTTP는 커넥션이 닫힌것을 보고 메시지가 끝났음을 인지했다.
그러나 Content-Length가 없다면 클라이언트는 커넥션이 정상적으로 닫힌건지, 전송중에 서버에 충돌이 발생한 것인지 구분하지 못한다. 메시지 잘림을 검출하기 위해 Content-Length 가 필요하다.
캐싱 프락시 서버에 특히 취약하다.
- 잘린 메세지를 수신했는데, 잘린걸 인식못하면 캐시는 결함이 있는 콘텐츠를 저장하고 계속 제공한다.
- 잘린 메세지를 캐시하는 위험을 줄이고자 캐싱 프락시 서버는 명시적으로 Content-Length헤더를 가지지 않은 HTTP 본문은 보통 캐시하지 않는다.

② 잘못된 Content-Length

Content-Length가 잘못된 값을 담고 있는 경우, 아에 빠진 것보다 더 큰 피해를 유발할 수 있다.
초창기 클라이언트,서버 중 일부는 Content-Length 계산과 관련된 잘 알려진 버그를 갖고 있어서
이런 오동작을 했는지 탐색하고 교정을 시도한다.
공식적으로 HTTP/1.1 사용자 에이전트는
잘못된 길이를 받고 그 사실을 인지 했을 때 사용자에게 알려주게 되어 있다.

③ Content-Length 와 지속 커넥션 (Persistent Connection)

Content-Length 는 지속 커넥션을 위해 필수다.
만약 응답이 지속 커넥션을 통해 온 것이라면, 또 다른 HTTP 응답이 즉시 뒤를 잇는다.
Content-Length 헤더는 클라이언트에게 메시지 하나가 어디서 끝나고 다음 시작이 어딘지 알려준다.
커넥션이 지속적이기 때문에, 클라이언트가 커넥션이 닫힌 위치를 근거로 메시지의 끝을 인식하는건 불가능.

④ 콘텐츠 인코딩

HTTP는 보안을 강화하거나 압축을 통해 공간을 절약할 수 있도록, 엔터티 본문을 인코딩할 수 있게 해준다.
만약 본문의 콘텐츠가 인코딩 되어 있다면,
Content-Length헤더는 인코딩 되지 않은 원본길이가 아닌 인코딩된 본문의 길이를 바이트단위로 정의한다.

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

엔터티 본문의 길이와 끝나는 위치를 바르게 판별하는 상황별 규칙. (나열된 순으로 적용해야 한다.)

1. 본문을 갖는 것이 허용되지 않는 특정 타입의 HTTP 메시지에서는 Content-Length 헤더가 무시된다.  
   (ex.HEAD method) 
2. 메세지가 Transfer-Encoding 헤더를 포함하고 있다면, 커넥션이 닫혀 먼저 끝나지 않는 이상,     
   엔터티는 '0 바이트 청크'라 불리는 특별한 패턴으로 끝나야한다. 
3. 메시지가 Content-Length 헤더를 갖는다면 (메시지 유형이 엔티티 본문을 허용한다면)  
   Transfer-Encoding 헤더가 존재하지 않는이상 Content-Length값은 본문 길이를 담는다.
4. 메시지가 `multipart/byteranges` 미디어 타입을 사용하고, 엔터티 길이가 별도 지정이 안됬다면,  
   멀티파트 메시지의 각부분은 각자가 스스로의 크기를 정의해야한다.
5. 위에 어떤 규칙에도 해당되지 않을때, 엔터티는 커넥션이 닫힐 때 끝난다.   
   (실질적으로 서버만 메시지가 끝났음을 알리기 위해 커넥션을 닫을 수 있다.)
6. HTTP/1.0 애플리케이션과의 호환을 위해, 엔터티 본문을 가진 HTTP/1.1 요청은 반드시 유효한  
   Content-Length 헤더도 가지고 있어야한다.
   1. 요청에 본문은 있으나 Content-Length헤더가 없는 경우,메시지 길이 판별 불가시 `400 Bad Request`
   2. 응답을 보내고 유효한 Content-Length를 보내고 싶다면 `411 Length Required` 응답을 보내라고 
       HTTP/ 1.1 명세에 조언한다.

03) 엔터티 요약

HTTP 가 일반적으로 TCP/IP 와 같이 신뢰할만한 전송 프로토콜 위에서 구현이 됨에도 불구하고 불완전한 트랜스코딩 프락시, 버그가 많은 중개자 프락시를 비롯한 여러 이유로 전송중 변형되는 일이 일어 난다.
엔터티 본문 데이터에 대한 의도치 않은 변경을 감지하기 위해 최초 엔터티가 생성될 때 송신자는 데이터에 대한 체크섬을 생성할 수 있고, 수신자는 모든 의도치 않은 엔터티의 변경을 잡기위해 체크섬으로 기본 검사를 할 수 있다.

04) 미디어 타입과 차셋(Charset)

Content-Type 헤더 필드는 엔터티 본문의 MIME 타입을 기술한다.
MIME 타입: 전달되는 데이터 매체의 기저형식의 표준화된 형식 (html, word, mpeg, video, ..etc)
- 주 미디어타입 / 부 타입(subtype)
  - 주미디어타입: text, image, audio, ..
  - 부 타입: 미디어타입을 조금 더 구체적으로 서술
클라이언트 어플리케이션은 콘텐츠를 적절히 해독하고 처리하기 위해 MIME 타입을 이용한다.
Content-Type 헤더가 원본 엔터티 본문의 미디어 타입을 명시하는것은 중요하다.
예를 들어, 엔터티가 콘텐츠 인코딩을 거친 경우에도 Content-Type 헤더는 여전히 인코딩 전의 엔터티 본문 유형을 명시할 것이다.

① 텍스트 매체를 위한 문자 인코딩

Content-Type 헤더는 내용유형을 더 자세히 지정하기 위한, 선택적인 매개변수도 지원한다.
엔터티의 비트 집합을 텍스트 파일의 글자들로 변환하기 위한 charset 매개변수가 대표 예.

Content-Type: text/html; charset=iso=8859-4

② 멀티파트 미디어 타입

'multipart' email 메세지는 서로 붙어있는 여러개의 메시지를 포함하며, 하나의 복합메시지로 보내진다.
각 구성 요소는 자족적으로 자신에 대해 서술하는 헤더를 포함한다.
여러 구성요소들이 이어져있고, 문자열 하나로 서로의 경계가 식별된다.
HTTP는 멀티파트 본문도 지원한다. (일반적으로 2가지 경우만 지원)
- 멀티파트 폼을 채워서 제출할 때
  - multipart/form-data 또는 multipart/mixed 헤더에 멀티파트 본문을 함께 보낸다.
    Content-Type: multipart/form-data; boundary=[abcdefghijklmnopqrstuvwzyz] boundary는 본문의 서로 다른 부분을 구분하기 위한 구분자로 쓰인다.
- 문서의 일부분을 실어 나르는 멀티파트 범위 응답을 할 때
  - 이러한 응답은Content-Type: multipart/byteranges 헤더 및 각기 다른 범위를 담은 멀티파트 본문이 함께 온다.

5) 콘텐츠 인코딩

HTTP 애플리케이션은 때때로 콘텐츠를 보내기 전에 인코딩을 하려 한다.
예
- 느린속도로 연결된 클라이언트에게 큰 HTML 문서를 전송하기 전에 서버는 전송시간을 줄이기 위해 압축
- 서버는 허가받지 않은 제 3자가 볼 수 없게 콘텐츠를 암호화하거나 뒤섞어 보낼 수 있음.
발송하는 쪽에서 콘텐츠에 적용하고, 콘텐츠 인코딩이 완료된 후에는 엔터티 본문에 담아 수신자에게 보낸다.

① 콘텐츠 인코딩 과정

1. 웹서버가 원본 Content-Type과 Content-Length 헤더를 수반한 원본 응답 메세지를 생성
2. 콘텐츠 인코딩 서버가 인코딩된 메세지 생성 (원서버 or 다운스트림 프락시)
    1. Content-Type 은 같지만 Content-Length는 다르다.
    2. 콘텐츠 인코딩 서버는 Content-Encoding헤더를 인코딩된 메시지에 추가하여,   
       수신측 애플리케이션이 그것을 디코딩 할 수 있도록 한다.
3. 수신측 프로그램은 인코딩된 메시지를 받아서 디코딩하고 원본을 얻는다.

② 콘텐츠 인코딩 유형

HTTP 는 몇가지 표준 콘텐츠 인코딩 유형을 정의하고, 확장 인코딩으로 인코딩을 추가하는것을 허용한다.
인코딩은 각 콘텐츠 인코딩 알고리즘에 의해 고유한 토큰을 할당하는 IANA를 통해 표준화된다.
Content-Encoding 헤더는 표준화된 토큰값을 이용해서, 인코딩에 사용된 알고리즘에 대해 기술한다.

흔히 쓰이는 콘텐츠 인코딩 토큰

  * gzip: Entity에 GNU zip 인코딩이 적용되었음을 의미 [일반적으로 가장 효율적이고, 널리 쓰임]
  * compress: Entity에 대해 유닉스 파일압축프로그램('compress')이 실행되었음을 의미.
  * deflate: Entity가 zlib 포맷으로 압축되었음을 의미.
  * identity: 
      - Entity에 어떤 인코딩도 수행되지 않았음을 의미. 
      - Content-Encoding 헤더가 존재하지 않는다면 이 값으로 간주한다.

gzip, compress, deflate: 무손실 압축 알고리즘 [전송되는 메세지 크기를 정보 손실없이 줄이는 알고리즘]

③ Accept-Encoding 헤더

서버에서 클라이언트가 지원하지 않는 인코딩을 사용하는 것을 방지하기 위해
클라이언트는 자신이 지원하는 인코딩 목록을 Accept-Encoding 요청헤더를 통해 전달한다.
만약 Accept-Encoding 이 포함되지 않다면 어떤 인코딩이든 클라이언트는 받아들인다는 것으로 간주.
[= Accept-Encoding: *]
사용 예: 필드에는 지원되는 인코딩들의 쉼표로 구분된 목록을 담는다.
```
  Accept-Encoding: compress, gzip
  Accept-Encoding: *
  Accept-Encoding: 
  Accept-Encoding: compress;q=0.5, gzip;q=1.0
  Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
```
- q값: '선호도'를 나타낸다(가장선호: 1.0, 비선호: 0.0)
- *: '그 외 모두'를 의미.
- identity : 오직 Accept-Encoding 헤더에만 존재 가능. 클라이언트에의해 다른 콘텐츠 인코딩 알고리즘에 대한 상대적 선호도 정의에 이용

6) 전송 인코딩과 청크 인코딩

전송인코딩 또한 엔터티 본문에 적용되는 가역적인 변환이지만,
구조적인 이유 때문에 적용되는 것이고, 콘텐츠의 포맷과는 독립적이다.

① 안전한 전송

전송인코딩은 다른 프로토콜에서도 네트워크를 통한 '안전한 전송'을 위해 존재했다.
표준화되고 더 너그러운 전송 기반을 갖춘 HTTP는 '안전한 전송'의 초점을 다른데 맞추고 있다.
HTTP에서 전송된 메시지의 본문이 문제를 일으킬 이유는 몇가지 없는데 2가지 살펴봄.
- 알 수 없는 크기: 몇몇 게이트웨이 애플리케이션과 콘텐츠 인코더는 콘텐츠를 먼저 생성하지 않고서는 메시지 본문의 최종 크기를 판단할 수 없다. 몇몇 서버는 데이터의 끝을 알리는 종결 꼬리말을 포함시켜, 전송 인코딩으로 데이터를 보내려 시도한다.
- 보안: 공용 전송 네트워크로 메시지 콘텐츠를 보내기전, 전송 인코딩을 사용해 알아보기 어렵게 뒤섞는 방법. 그러나 이미 SSL과 같은 유명한 전송 게층 보안 방식이 있어서 흔치 않다.

② Transfer-Encoding (전송 인코딩)

전송 인코딩을 제어하고 서술하기 위해 정의된 헤더 (단 2가지)
- Transfer-Encoding: 안전한 전송을 위해 어떤 인코딩이 메시지에 적용되었는지 수신자에 알린다.
- TE: 어떤 확장된 전송 인코딩을 사용할 수 있는지 서버에 알려주기 위해 요청헤더에 사용한다.

③ Chunked Encoding (청크 인코딩)

청크 인코딩은 메시지를 일정 크기의 청크 여럿으로 쪼갠다.
서버는 각 청크를 순차적으로 보낸다.
청크 인코딩을 사용하면 메시지를 보내기 전에 전체 크기를 알 필요가 없다.
본문이 동적으로 생성됨에 따라, 서버는 그 중 일부를 버퍼에 담은 뒤 한 청크를 그것의 크기와 함께 보낼 수 잇다. 본문 전체를 보낼 때까지 이 단계를 반복한다.
청크 인코딩이 전송인코딩의 한 형태이며 따라서 본문이 아닌, 메시지의 속성을 주목.

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

콘텐츠 인코딩과 전송 인코딩은 동시에 사용될 수 있다.
전송 인코딩이 메시지 본문에 적용될 때 몇가지 규칙이 적용되야한다. (p414)

7) 시간에 따라 바뀌는 인스턴스

웹 객체는 정적이지 않다.
같은 URL은 시간에 따라 다른 버전의 객체를 가리킬 수 있다.
HTTP 프로토콜은 어떤 특정한 종류의 요청이나 응답을 다루는 방법을 정의한다.[=인스턴스 조작]
대표적인 2가지
- 범위 요청
  - HTTP 클라이언트는 받다가 실패한 엔터티를 일부 혹은 범위로 요청함으로써, 다운로드를 중단된 시점에서 재개할 수 있다.
  - 또한 여러 범위로 요청하기 위해 사용될 수 있다. 다운로드 시간을 줄이기 위해 여러 서버에 접속해서 같은 문서에 대해 서로 다른 범위를 요청하는 클라이언트의 경우.
- 델타 인코딩
  - 객체 전체가 아닌, 변경된 부분에 대해서만 통신하여 전송량을 최적화하는 HTTP프로토콜의 확장.
위 2가지 모두 클라이언트가 자신이 갖고 있는 리소스 사본과 서버가 가진 것이 정확히 같은지 판단하고 상황에 따라 새 인스턴스를 요청할 수 있는 능력을 가질 것을 요구한다.

8) 검사기와 신선도

ch07 참조 (메모 생략)

Previous14. Secure HTTP Next16. Internationalization

Last updated 3 years ago