HTTP완벽가이드 스터디 15, 16장

15장 엔터티와 인코딩

http://tlog.tammolo.com/blog/15-8c6042c9-bdcf-41ca-b5e8-4169a5a80055/

이 장에서 다룰 내용들

• HTTP 데이터를 담는 컨테이너인 HTTP 메시지 엔터티의 포맷과 동작방식
• 어떻게 HTTP가 엔터티 본문의 크기를 기술하며, 크기를 측정하기 위해 HTTP가 무엇을 요구하는지
• 클라이언트가 콘텐츠를 바르게 처리할 수 있도록 제공하는 엔터티 헤더들
• 공간을 적게 차지하고 더 안전하게 만들기 위해 발송자가 콘텐츠 데이터 포맷을 변형할 때 사용하는, 디코딩 가능한 콘텐츠 인코딩
• 특정 종류의 콘텐츠의 송수신을 개선하기 위해 HTTP가 데이터를 실어 나르는 방식을 수정하는 전송 인코딩. 그 중에서도 길이를 알 수 없는 콘텐츠를 안전하게 전송하기 위해 데이터를 여러 조각으로 쪼개 전달하는 청크 인코딩
• 클라이언트가 요청한 콘텐츠의 최신 버전을 가져올 수 있도록 도와주는 태그, 라벨, 시간, 체크섬의 모음
• 콘텐츠의 버전 번호처럼 동작하는 검사기들. 그리고 객체를 최신으로 유지하기 위해 설계된 HTTP 헤더 필드들
• 중단되었던 다운로드를 중단된 지점에서부터 재개하고자 할 때 유용한 범위 요청
• 클라이언트가 전에 본 적이 있었던 웹 페이지를 다시 볼 때, 그때 이후로 변경이 있는 부분만 요청할 수 있게 해주는 HTTP 델타 인코딩 확장
• 엔터티 콘텐츠가 프락시를 지나는 과정에서 변경된 곳이 있지 않은지 탐지하기 위해 사용하는, 엔터티 본문의 체크섬

HTTP는 메시지가 올바르게 수송되고, 식별 되고, 추출 되고, 처리 되는 것을 보장한다.

• 객체는 올바르게 식별되므로 브라우저나 다른 클라이언트는 콘텐츠를 바르게 처리 할 수 있다. (Content-Type)
• 객체는 올바르게 압축이 풀릴 것이다. (Content-Type, Content-Encoding)
• 객체는 항상 최신이다. (엔터티 검사기와 만료 제어)
• 사용자의 요구를 만족할 것이다. (Accept)
• 네트워크 사이를 빠르고 효율적으로 이동할 것이다. (범위 요청, 델타 인코딩, 압축)
• 조작되지 않고 온전하게 도착할 것이다. (Content-MD5)

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 엔터티 본문

엔터티 본문에는 다양한 타입의 데이터가 올 수 있다. 이 부분은 클라이언트에게 설명하기 위해서 Content-Type 헤더에 본문에 대한 타입을 알려준다.

15.2 Content-Length : 엔터티의 길이

엔터티의 본문의 길이로 gzip으로 압축된 텍스트 파일이라면 압축 후의 크기다.

Content-Length는 청크 인코딩으로 전송하지 않는 이상 항상 포함 시켜야 한다.

15.2.1 잘림 검출

Content-Length가 없다면 클라이언트는 커넥션이 정상적으로 닫힌 것인지 아니면 메시지가 충돌 난것이 구분하지 못한다. 특히 메시지 잘림을 감지 못한 캐시 서버가 있다면 문제 크다.

15.2.2 잘못된 Content-Length

아얘 없는 것보다 나쁘다.

15.2.3 Content-Length와 지속 커넥션

이 부분은 커넥션 다룰 때 언급 되었다. 지속 커넥션은 하나의 커넥션으로 다양한 메시지를 받고 새로 받은 메시지의 인덱스를 알고 있으려면 길이를 통해 계산을 해야 한다. 그렇기 때문에 지속 커넥션에서 Content-Length에 대한 의존성은 크다.

15.2.4 콘텐츠 인코딩

HTTP는 보안을 강화하거나 압축을 통한 효율적인 통신을 하기 위해 본문을 인코딩 한다.

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

1. Header와 같이 본문이 없는데 Content-Length 값을 가질 때는 무시한다.
2. 메시지가 Transfer-Encdoing 헤더를 포함하고 있다면 엔터티는 '0바이드 청크'라고 불리는 특별한 패턴으로 끝나야 한다.
3. 메시지에 Transfer-Encoding 헤더를 포함하면 Content-Length가 무시된다. 이 때는 본문을 표현하고 전송하는 방식을 바꿀 것이기 때문이다.
4. 메시지의 타입이 'multipart/byteranges' 면 메시지의 각 부분의 크기를 스스로 정할 것이다. 이 유형은 유일하게 자신의 크기를 스스로 결정한다.
5. 엔터티는 커넥션이 닫 힐 때 끝난다. 클라이언트는 절반 끊기를 할 수 있지만 커넥션을 닫을 수 없다.
6. Content-Length가 포함되지 않은 요청에 대해서 411 Length Required 응답을 주라고 조언한다.

15.3 엔터티 요약

HTTP가 TCP/IP위에서 신뢰적인 통신을 보장한다고 하지만, 중간에 프락시도 있고 여러가지 이유 때문에 메시지의 일부분이 변형되는 일이 있을 수 있다. 이런 상황을 감지하고자 체크섬을 사용하기도 한다.

Content-MD5 헤더는 미리 서버가 만든 계산 된 값을 클라리언트에게 보낸다. 클라이언트는 메시지를 인코딩 하여 Content-MD5 값과 비교하여 메시지가 정상적으로 도착했다는 것을 할 수 있다. 이렇게 유용하지만 실제로는 자주 사용되지 않는다고 한다.

15.4 미디어 타입과 Charset

Content-Type 헤더 필드에는 MIME 타입을 기술한다. MIME 타입은 주 타입/부 타입으로 구성되어 있는데 대표적인 예는 아래와 같다.

text/html, text/plain, image/gif, image/jpeg, audio/x-wav, model/vrml, multipart/byteranges, message/http, 등이다.

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

다음 처럼 선택적으로 매개변수를 추가적으로 넣을 수 있다.

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

15.4.2 멀티파트 미디어 타입

서로 붙어 있는 여러 개의 메시지를 포함하며, 하나의 복합 메시지로 보내진다.

15.4.3 멀티파트 폼 제출

boundary를 사용하여 각 파트를 구별할 수 있다.

POST /foo HTTP/1.1

Content-Length: 68137

Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575

 

-----------------------------974767299852498929531610575

Content-Disposition: form-data; name="description" 

 

some text

-----------------------------974767299852498929531610575

Content-Disposition: form-data; name="myFile"; filename="foo.txt" 

Content-Type: text/plain 

 

(content of the uploaded file foo.txt)

-----------------------------974767299852498929531610575--

 

15.4.4 멀티파트 범위 응답

응답 또한 멀티파트가 될 수 있다. 404p

15.5 콘텐츠 인코딩

효율적으로 통신하기 위해 콘텐츠를 인코딩 할 수 있다.

15.5.1 콘텐츠 인코딩 과정

원본의 길이를 포함한 애용을 gzip으로 압축한다. 그리고 압축한 크기와 Content-encoding: gzip 헤더를 포함하여 전송한다. 수신자는 gzip으로 압축하고 원본의 길이를 얻어낸다.

15.5.2 콘텐츠 인코딩 유형

gzip, compress, delate, identity 가 있지만 gzip이 가장 효율이 좋다고 한다. 나머지 모두 무손실 압축 알고리즘

15.5.3 Accept_Encoding 헤더

클라이언트가 처리 가능한 인코딩 방식을 명시 그런데 재미난게 있다.

Accept-Encoding: gzip; q=1.0, identity; q=0.5 *;q=0

위 처럼 적었을 때 q는 선호도를 나타낸다. 이 값은 0 부터 1.0까지 의 소수 값이고 값이 클수록 선호 하는 것이다.

gzip은 완전 선호하는 것이고, identity는 soso이고 나머지는 싫다는 것이다.

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

text에 대해서 gzip은 꽤 효율적이다. 그런데 JPEG 같은 이미지는 gzip으로 잘 압축되지 않는다. 전송 인코딩은 포맷과는 독립적이지만 메시지 데이터가 네트워크를 통해 전소되는 방법을 바꾸기 위해 사용한다.

15.6.1 안전한 전송

전송 인코딩은 안전한 전송을 위해 존재했다. 전송 인코딩을 사용 하는 주요 이유는 두 가지다. 메시지에 Content-Length를 포함하지 않는 경우 몇몇 게이트 웨이나 서버는 전송 인코딩으로 데이터를 보내려 한다. 또 다른 이유는 보안의 이유다. 이 경우는 SSL의 등장으로 거의 사용하지 않는다.

15.6.2 Transfer-Encoding 헤더

Transfer-Encoding : 어떤 인코딩을 적용했는지 수신자에게 알린다.

TE : 어떤 전송 인코딩을 사용할 수 있는지 서버에게 알린다.

여기에도 선호를 나타내는 Q 값을 쓸 수 있다. 명세에는 0.0값은 금지

15.6.3 청크 인코딩

메시지를 여러 청크로 쪼갠다. 이렇게 하면 크기를 알 필요가 없어진다. Content-Length를 따로 알려주지 않고 일정 크기의 청크를 계속 보내고 다 보내면 크기가 0인 청크를 보낸다.

마지막 청크 다음에는 트레일러와 올 수 있는데, 클라이언트의 TE 헤더에 트레일러를 받을 수 있으면 트레일러에 필요한 헤더를 포함시킬 수 있다.(Transfer-Encoding, Trailer, Content-Length 제외

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

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

15.6.5 전송 인코딩 규칙

414p

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

지금의 서버응답과 내일의 서버응답이 다를 수 있다.

15.8 검사기와 신선도

어제 받은 데이터와 오늘 받은 데이터가 동일하면 새로 받을 필요가 없다. 이 부분은 요청 헤더 쪽에서도 다뤘던 내용이다.

15.8.1 신선도

Expires, Cache-Control 헤더를 통해 신선도를 체킹할 정책을 정한다.

15.8.2 조건부 요청과 검사기

If-Modified-Since 헤더등을 사용,

약한 검사, 강한 검사기 (ETag)

15.9 범위 요청

브라우저에서 어떤 데이터를 다운로드 받을 때 받을 양을 표현하거나 끊긴 부분을 이어 받을 때 사용할 수 있을 것이다.

GET /bigfile.html HTTP/1.1

Host: www.joes-hardware.com

Range: bytes=4000-

User-Agent: Mozilla/4.61 [en] (WinNT; I)

...

 

15.10 델타 인코딩

어떤 문서에서 일부분만 변경되었을 때도 전체를 가져오고, 오타 하나 수정해서 전체를 가져오는 것 보다는 변경 사항만 가져오는 것이 효율적일 것이다.

423P

15.10.1 인스턴스 조작, 델타 생성기 그리고 델타 적용기

424P

16장 국제화

http://tlog.tammolo.com/blog/16-a65c0dc1-5da4-4fcb-b013-7e324c91d16c/

웹을 이용하는 사용자는 다양한 언어로 문서를 작성한다. HTTP는 여러 언어와 문자로 된 국제 문서들의 처리 및 전송을 지원해야 한다.

이 장에서 다룰 내용은 다음과 같다.

• HTTP가 어떻게 여러 언어 문자들의 체계 및 표준과 상호작용하는지 설명한다.
• HTTP 프로그래머가 올바르게 업무를 수행하는데 도움이 될 수 있도록 전문용어, 기술, 표준의 간략한 개요를 제공한다.
• 언어를 위한 표준 명명 체계와, 어떻게 표준화된 언어 태그가 선택한 콘텐츠를 서술하는지에 대해 설명한다.
• 국제화된 URI의 규칙과 주의사항을 개괄적으로 서술한다.
• 날짜와 그 외 다른 국제화 이슈에 대해 간단히 논의한다.

16.1 국제적인 콘텐츠를 다루기

HTTP에서 엔터티 분몬이란 그저 비트들로 가득 찬 상자에 불과 하다. 국제 콘텐츠를 지원하기 위해 서버는 클라이언트에게 각 문서의 문자와 언어를 Content-Type charset과 Content-Language 헤더를 통해 알려준다. 서버는 국제화를 위해 다양한 언어의 문서를 준비할 수 있다. 클라이언트는 요청을 보낼 때 어떤 언어의 문서를 원하는지 다음의 방식으로 알릴 수 있다.

Accept-Language: fr, en;q=0.8

Accept-Charset: iso-8859-1, utf-8

 

16.2 문자 집합과 HTTP

16.2.1 차셋(Charset)은 글자를 비트로 변환하는 인코딩이다.

charset의 예로는 us-ascii, ios-8859-1, euc-kr, utf-8 등이 있다. HTTP 메시지에서는 아래의 예처럼 헤더에 문서의 차셋을 표현한다.

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

 

16.2.2 문자 집합과 인코딩은 어떻게 동작하는가

인코딩은 두 단계에 걸쳐 일어난다. bits → character code → unique charater

16.2.3 잘못된 차셋은 잘못된 글자들을 낳는다.

위 이미지에서 iso-8859-6 문자 체계에서 character code 가 225인 문자가 아래의 문자로 인코딩 되어 표현되는 것을 확인 했다.

같은 225 character code가 또 따른 문자 체계에서는 다르게 보일 수 있다.

iso-8859-1

iso-8859-7

iso-8859-8

á

α

16.2.4 표준화된 MIME 차셋 값

Language Code Table

16.2.6 Content-Type charset 헤더와 META 태그

HTTP 메시지에 아래 처럼 MIME 차셋 태그를 헤더에 담아 보낸다.

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

 

만약 문자 집합이 명시적으로 나열되지 않았다면, 수신자는 문서의 콘텐츠를 통해 문자 집합을 추측하려 시도한다. HTML 문서에는 문자 집합을 나타내는 <META HTTP_EQUIV="Content-TYpe"> 태그가 있다.

...

<HEAD>

    <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-2022-jp">

</HEAD>

<BODY>

...

 

16.2.6 Accept-Charset 헤더

클라이언트는 자신이 처리할 수 있는 선호하는 방법을 요청한다. 다만, 서버가 모든 인코딩 방식을 지원하지 않기 때문에 요청한 방식을 고려해서 응답을 내려준다.

Accept-Language: fr, en;q=0.8

Accept-Charset: iso-8859-1, utf-8

 

16.3 다중언어 문자 인코딩에 대한 지침

16.3.1 문자집합 용어

글리프, 코딩된 문자, 코드 공간, 코드 너비, 사용 가능 문자집합, 코딩된 문자집합, 문자 인코딩 구조 등 용어 정리를 하지만 나는 관심 없어서..

16.3.2 'Charset은 형편없는 이름이다.

차셋(Chatset)은 문자 인코딩 구조와 코딩된 문자집합의 개념을 합친 것으로 RFC 2277에서 이용어가 언급 된다. RFC 2616에는 character set 이라는 용어를 사용하기도 한다.

???

16.3.3 문자

하나의 문자가 용도(수학기호, 구두점 등에 따라 다르게 표현된다.

같은 글자가 위치에 따라 다르게 표기되기도 한다.

16.3.4 글리프(glyphs), 연자(ligatures) 그리고 표현 형태

f와 i 이 만날 때 i의 ' 이 사라지도록 표현하는데 fi 연자가 존재하면 사라지도록 표현하고 아니면 그냥 표현한다.

16.3.5 코딩된 문자집합(Coded Character Set)

ascii라 불리는 us-ascii, iso-8859 시리즈(iso-8859-1, iso-8859-2...)

6.3.6 문자 인코딩 구조

고정폭, 가변폭이 있는데 가변폭은 모달형과 비 모달형이 있다. iso-8859 시리즈는 8비트 고정폭을 사용한다. 가변폭(모달)의

가변폭 (비모달) 예 UTF-8

UTF(Universal character set Transformation Foramt)

UTF-8은 전세계의 문자를 표현하는 가장 대표적인 문자 집합으로 비모달 가변길이 인코딩 방식이다. 최대 6바이트

57 → 00111001

245 → 11110101 → 11000011 10110101

536 → 1001111010001 → 11100001 10001111 10010001

Unicode와 UTF-8

U+AC00 → 10101100 00000000 utf-8→ 11101010 10110000 10000000

EUC-KR(Extended Unix Code-KR)

KS X 1003: 0-127의 ascii 에 \만 원화로 바꾼 것 KS X 1001: 가 → b0a1, 갓 → b0ab

갷은 ?? 어떻게 표현하지 ??

한글 채움 문자(fill code: 0xA4 OxD4)를 사용

(0xA4 OxD4) ㅈ ㅣ ㅂ → 집

http://i18nl10n.com/korean/euckr.html

16.4 언어 태그와 HTTP

한국은 ko-KR, 미국은 en-US

16.4.1 Content-Language 헤더

16.4.2 Accept-Language 헤더

16.4.3 언어 태그의 종류

http://www.lingoes.net/en/translator/langcode.htm

16.4.4 서브 태그

16.4.5 대소문자의 구분 및 표현

언어는 소문자, 국가는 대문자

16.4.6 IANA 언어 태그 등록

http://xml.coverpages.org/TexinUsingLangID.html

16.4.7 첫 번째 서브태그: 이름 공간

언어를 나태는 첫 번째 서브태그는 ISO 639 표준을 따르는 것이 일반적이다.

16.4.8 두 번째 서브태그: 이름공간

두 번째 서브태그는 ISO 3166에 있는 국가 코드와 지역 표준 집합을 따른다.

16.4.9 나머지 서브태그: 이름공간

영어나 숫자인 것 외 별도의 규칙이 없다.

16.4.10 선호 언어 설정하기

브라우저에서 설정하자.

16.4.11 언어 태그 참조표

16.5 국제화된 URI

URI는 국제화를 그닥 지원하지 않음.