[HTTP 프로토콜 강좌]#21 HTTP 엔티티 헤더 I - Content-Encoding, Content-Language, Content-Length, Content-Location, Content-Type, Content-Range

오늘부터 이틀간 HTTP 헤더의 마지막인 엔티티(Entity) 헤더를 다루게 된다.
메시지 바디 부분에 포함되는 부분의 정보를 담는 것이다 보니 주로 응답헤더쪽에 많이 사용된다.

오늘은 엔티티 헤더 중 주로 Content 로 시작하는 헤더를 이야기 한다.

1. Content-Encoding
2. Content-Language
3. Content-Length
4. Content-Location
5. Content-Type
6. Content-Range

총 6개에 해당하는 내용이지만, 각 헤더별로 살펴볼 내용이 그리 많지는 않다.


1. Content-Encoding

웹서버가 응답으로 전달하는 메시지의 인코딩 방식을 명시하는 헤더이다.
주로 Content-Type 헤더와 같이 사용되며, Content-Type 은 전달하는 컨텐츠의 포맷을 나타낸다.

예로, 다음과 같이 클라이언트가 요청한 aaa.pdf 파일에 대한 응답 결과를 보자.

위와 같이 웹서버의 응답헤더에서 Content-Encoding, Content-Type 부분을 보면,

• Content-Type : application/pdf
• Content-Encoding : gzip

이다. 

문서가 PDF 형태의 문서였으니 Content-Type 에 'application/pdf' 형태로 나타냈고, 전달하는 메시지 인코딩 방식은 'gzip' 을 이용해서 전달한다는 의미이다. 

이렇듯, Content-Encoding 은 전달하는 메시지의 압축방식과 관련이 깊다. 

HTTP 에서는 Content-Encoding 의 값으로 총 4가지를 사용할 수 있음을 정의하고 있다. 

1. compress : 유닉스 시스템에서 사용하는 압축방식이다. 
2. deflate : zlib 압축 포맷이다. 이는 RFC 1950에 정의되어 있다. 
3. gzip : gzip 프로그램을 이용하여 압축한 형태이다. RFC 1952에 정의되어 있다. 
4. identity : 특정한 압축 포맷이 사용되지 않았음을 의미한다. 

Content-Encoding 은 앞서 배웠던 HTTP 메시지 전송방식의 Transfer-Encoding 과는 비슷하면서도 차이가 있다. 

Content-Encoding 은 전달하는 컨텐츠 본래의 형태이지만, Transfer-Encoding 은 HTTP 서버에 의해 적용되는 컨텐츠 전송 방식인 것이다. 

* Transfer-Encoding 헤더의 자세한 내용은 여기 를 통해 확인 할 수 있다. 

2. Content-Language 

전달되는 컨텐츠 자체의 언어를 정의하는 헤더이다. Content-Language 의 값의 형태는 Accept-Language 와 같다.

Accept-Language 헤더의 자세한 내용은 여기 를 통해 확인 가능하다.

Content-Language 는 한국어,영어와 같은 인간의 언어를 표시한다. 컴퓨터언어인 C나 자바가 아님은 참고로 알아 두자.





3. Content-Length

메시지 바디의 전체 사이즈를 뜻하는 헤더이다. 보통 바이트 단위로 표시된다.
여기서.. 한가지 문제..
우리가 앞서 HTTP 요청 방식 중 HEAD 를 배웠었다. HEAD는 GET과는 달리 응답헤더만 요구할뿐 컨텐츠 자체는 되돌려주지 않는다.
그럼 HEAD 방식으로 컨텐츠를 요청했을때 메시지 바디가 없는데.. 이때의 Content-Length는 어떻게 표시될까?
그렇다. HEAD 로 요청한다고 해도, Content-Length에는 메시지 바디의 전체 사이즈를 표시해서 응답을 하게 된다.

Content-Length는 HTTP 1.1 환경에서 반드시 필요한 헤더 정보이다. 수신자는 이 정보를 참고하여 자신이 요청한 컨텐츠의 시작과 끝을 결정한다.

수신자가 컨텐츠의 시작과 끝을 결정하는 것에 다른 정보를 활용하기도 한다.
앞서 배웠던 Transfer-Encoding 의 Chunked 방식이 있고.. 또한 TCP 커넥션의 종료도 메시지바디의 마지막으로 인식한다.

다음은 수신자가 컨텐츠의 마지막을 결정하는 방식을 정리한 것이다. 아래 순서는 우선순위를 의미하기도 한다.

1. 응답메시지의 상태코드가 1xx, 204, 304 인 경우 컨텐츠 자체를 포함하지 않기 때문에 헤더필드 다음의 공백 라인이 메시지의 끝이다.
2. Transfer-Encoding 방식이 Chunked 인 경우 Chunked 전송방식과 같이 메시지바디의 끝에 '0' 을 표시하여 끝을 알린다. 
3. Content-Length 에 표시된 전체 바이트를 참고하여 수신 바이트를 계산한다.
   계산된 바이트를 모두 전송받은 경우가 메시지 바디의 끝이다. 
4. Content-Type 의 헤더값이 multi-part/byteranges 인 경우 미디어 타입 형태에서 끝을 명시한다. 
5. 서버의 TCP 커넥션이 끊어진 경우 서버로부터 전송받은 마지막 바이트가 메시지 바디의 끝부분이다.  

4. Content-Location

Content-Location 헤더는 메시지 바디와 관련된 URI 정보를 제공하는 헤더이다.
클라이언트의 Accept-Language 헤더 정보를 이용해서 사용자의 언어환경을 파악한 후 적절한 언어의 서비스 URI 를 전달하려 할때 활용할 수 있다.

예를 들어 웹서버가 다중 언어를 지원하는 형태로 개발되었다고 하자.
영어환경의 사용자에게는 영문 메인페이지 URI를... 한국어 사용자에게는 한글 메인페이지 URI를 제공하려면, Content-Location 헤더를 이용하면 된다.

Accept-Language: en-US 인경우, 응답헤더의 Content-Location: /main_us.html 를...
Accept-Language: ko-KR 인경우, 응답헤더의 Content-Location: /main_ko.html

이런식으로 처리하게 되면, 영어사용자에게는 영문홈페이지를, 한국어 사용자에게는 한글 홈페이지를 접속하게 할 수 있는것이다.

하지만, 생각보다 Content-Location 헤더의 사용빈도가 그리 높지는 않다. Location 헤더의 사용 빈도가 매우 높기 때문이다.

Location 헤더의 상세한 내용은 여기 를 통해 확인할 수 있다.

클라이언트가 접하는 결과물로 보면 이 두헤더가 비슷하지만 Content-Location 과 Location 헤더에는 차이점이 있다.

Content-Location 에 명시된 URI 가 메시지 바디 자체를 회신하는 것이지만, Location 에 표시된 URI는 클라이언트를 다른 URI로 라디이렉트 하는 것이다.

즉, 클라이언트가 요청한 컨텐츠의 메시지 바디가 Content-Location 의 URI 에는 직접 포함되어 있으나, Location 헤더의 URI에는 메시지 바디와 직접적인 연관이 없는 경우가 크다.

5. Content-Type

Content-Type 헤더는 클라이언트가 요청한 컨텐츠의 형태를 표시하는 헤더이다.
Content-Type 의 형태는 다음과 같다.

•  Content-Type: 주타입 / 서브타입

이미 지난 시간에 다뤘던 Accept 헤더와 형태가 비슷하다.

다음은 실제 사용된 응답 헤더의 내용이다. (제일 마지막 라인 참고)

Content-Type 헤더의 값으로 메인 타입(image) 와 서브타입(png) 를 확인 할 수 있다.
Content-Type 헤더에는 아래 예와 같이 메시지 바디의 문자셋(Character-set) 을 추가적으로 명시할 수도 있다.

Content-Type: text/plain; Charser=ISO-8859-4




6. Content-Range

클라이언트가 대용량의 파일을 웹서버에서 다운로드를 하다가 중간에 끊기는 일이 발생했다. 클라이언트가 Range 헤더를 이용해서 끊긴 부분부터 다시 다운 받기를 시도하는 경우 웹서버는 Accept-Range 헤더와 함께 이어서 파일을 전송해 줄수 있다는 것을 이전 시간에 배운바 있다.

Range 헤더와 Accept-Range 헤더의 자세한 내용은 다음을 참고토록 하자.

• Range 헤더 : 여기 를 클릭
• Accept-Ragne 헤더 : 여기 를 클릭

Range 헤더를 이용해서 파일을 이어받으려는 경우 웹서버는 Accept-Range 헤더와 함께 클라이언트가 요청한 부분부터 데이터를 전송한다는 정보를 전달하는데 바로 이때 사용되는 헤더가 Content-Range 헤더이다.

위와 같이 웹서버가 다시 전송을 시작하는 시점을 Content-Range 에 표시한다.

끝~