HTTP 1.1 Header

1. Team-Mobs 박 기 덕
HTTP 헤더

2. HTTP 헤더의 탄생
• HTTP 최초 버전인 0.9에는 헤더가 없었다.
• 메타데이터를 표현하기 위해 전자메일의 메시지 스펙(RFC822)의 헤더 형식을 인용해 추가
• 때문에 아래와 같은 전자메일과 공통적인 헤더 부분이 다수 존재
Content-Type
Content-Length
Date
이외 다수 존재…
• 전자메일은 한 방향으로 메시지를 요청하고 응답을 받지 않으며, HTTP는 한번의 통신으로 요청/응답을 처리

3. 날짜와 시간
이용하는 메시지 헤더 의미
요청과 응답 Date 메시지를 생성한 일시
요청 If-Modified-Since 조건부 GET으로 리소스의 갱신일시를 지정할 때 이용
If-Unmodified-Since 조건부 PUT, 조건부 DELETE로 리소스의 갱신일시를 지정할 때 이용
응답 Expires 응답을 캐시 할 수 있는 기한
Last-Modified 리소스를 마지막으로 갱신한 일시
Retry-After 다시 요청을 전송할 수 있는 일시의 기준
• 그리니치 표준시(GMT)를 사용해 날짜와 시간 표시

4. MIME 미디어 타입
• 메시지를 주고 받는 리소스 표현의 종류를 지정
• 전자메일의 헤더에서 인용한 스펙으로 HTTP에서는 Content-Type 등 몇 개의 헤더만을 이용
• Content-Type
• 메시지의 바디 내용이 어떠한 종류인가를 미디어 타입으로 표시
Content-Type : application/xhtml + xml; charset = utf-8
• 위의 예에서 application이 타입, xhtml + xml이 서브타입
• 타입의 종류는 RFC 2045(메시지 포맷), RFC 2046(미디어 타입) 에서 정의된 타입만 사용, 서브타입의 종류는 비교적
자유롭게 생성 가능

5. MIME 미디어 타입 (TYPE)
타입 의미 예
text 사람이 읽고 직접 이해할 수 있는 텍스트 text/plain
image 그림 데이터 image/jpeg
audio 음성 데이터 audio/mpeg
video 동영상 데이터 video/mp4
application 그 밖의 데이터 application/pdf
multipart 복수의 데이터로 이루어진 복합 데이터 multipart/related
message 전자메일 메시지 message/rfc822
model 복수 차원으로 구성하는 모델 데이터 model/vrml
example 예시용 example/foo-bar

6. MIME 미디어 타입(SUB TYPE)
타입/서브타입 의미 타입/서브타입 의미
text/plain 플레인 텍스트 application/atomsvc+xml Atom의 서비스 문서
text/csv CSV형식 텍스트 application/atomcat+xml Atom의 카테고리 문서
text/css CSS형식의 스타일 시트 application/javascript JavaScript
text/html HTML 문서 application/json JSON 문서
text/xml XML 문서 (비추천) application/msword Word 문서
image/jpeg JPEG 이미지 application/vnd.ms-excel Excel 문서
image/gif GIF 이미지 application/vnd.ms-powerpoint PowerPoint 문서
image/png PNG 이미지 application/pdf PDF 문서
application/xml XML 문서 application/zip ZIP 파일
application/xhtml+xml XHTML 문서 application/x-shockwave-flash Flash 오브젝트
application/atom+xml Atom 문서 application/x-www-form-urlencoded HTML 폼 형식

7. MIME 미디어 타입
• 미디어 타입은 charset 파라미터를 가질 수 있다.
• charset은 생략 가능하지만 text 타입의 경우 주의가 필요
• text타입의 디폴트 문자 이코딩은 ISO 8859-1로 정의되기 때문에 생략 시 한글 텍스트가 깨질 수 있다.
• XML 문서 자체에서 인코딩 방식을 선언해도 text타입은 Content-Type 헤더의 charset 파라미터를 우선
• text타입의 경우 반드시 charset 파라미터를 붙여야 한다.
• 또한 text/html 사용을 자제하고, application/xml 혹은 application/xhtml+xml 사용을 권고

8. MIME 미디어 타입
• XML이 선언한 문자 인코딩 지정을 무시하는 예
HTTP/1.1 200 OK
Content-Type : text/html
<?xml version=“1.0” encoding=“utf-8”?>
<test>한글 텍스트</test>
• 바르게 문자 인코딩을 지정한 예
HTTP/1.1 200 OK
content-Type : application/xml; charset=utf-8
<?xml version=“1.0” encoding=“utf-8”?>
<test>한글 텍스트</test>

9. 언어 태그
• Content-Language 헤더는 리소스 표현의 자연언어를 지정
Content-Language : ko-KR
• 언어 태그의 „-‟ 왼편에는 ISO 639(언어의 약자)가 정의한 언어코드
• 언어 태그의 „-‟ 오른편에는 ISO 3166(지역의 약자)가 정의한 지역코드
• ISO 639, ISO 3166에는 2글자의 약자와 3글자의 약자가 있는데 보통 2글자의 약자를 사용

10. 콘텐트 네고시에이션
• 클라이언트와 교섭해서 미디어 타입을 정함
• 클라이언트가 자신이 처리할 수 있는 미디어 타입을 서버에게 전달할 경우 Accept 헤더를 이용
Accept : text/html, application/xhtml+xml, application/xml; q=0.9, */*; q=0.8
• 클라이언트가 지정한 미디어 타입을 서버가 대응하지 않는다면 406 Not Acceptable 반환
요청 GET /test HTTP/1.1
Host : example.com
Accept : application/xml, application/msword;q=0.9
응답 HTTP/1.1 406 Not Acceptable

11. 콘텐트 네고시에이션
• 클라이언트 자신이 처리할 수 있는 문자 인코딩을 서버에 전달할 때 Accept-Charset 헤더를 이용
Accept-Charset : EUC-KR, utf-8; q=0.7, */* ; q=0.7
• 클라이언트 자신이 처리할 수 있는 언어 태그를 서버에 전달할 때 Accept-Language 헤더를 이요
Accept-Language : ko, en-us; q=0.7, en; q=0.3

12. CONTEN-LENGTH와 청크(CHUNK) 전송
• 메시지가 바디를 가지고 있을 때, 기본적으로 Content-Length 헤더를 이용, 사이즈를 10진수의 바이트로 표현
Content-Length : 5583
• 동적으로 생성하여 전송하는 경우 전체 파일사이즈가 정해지지 않아도 전송 가능
Transger-Encoding : chunked
• 다음과 같이 분할하여 전송 가능, Chunk의 구분을 위하여 마지막에는 반드시 길이가 0인 Chunk와 빈줄을 붙임
POST /test HTTP/1.1 10
Host : example.com The brow fox ju
10
Transfer-Encoding : chunked mps quickly over
Content-Type : text/plain; charset=utf-8 e
the lazy dog.
0
(빈 공백 삽입)

13. 인증
• HTTP 1.1이 규정하는 Basic 인증과 Digest 인증, 웹 API에서 HTTP 인증의 확장으로 WSSE 사용
• 리소스에 엑세스 제어가 걸려있을 때, 스테이터스 코드 401 Unauthorized, WWW-Authenticate 헤더 이용
요청 DELETE /test HTTP/1.1
Host : example.com
응답 HTTP/1.1 401 Unauthorized
WWW-Authenticate : Basic realm=“example.com”
• realm은 URI공간의 이름, URI공간은 패스 이하를 가르킴

14. 인증 (BASIC)
• Basic 인증은 유저 이름과 패스워드에 의한 인증 방식
DELETE /test HTTP/1.1
Host : example.com
Authorization : Basic dXNlcjpwYXNzd29yZA==
• Authorization 헤더의 내용은 유저 이름과 패스워드를 „:‟로 연결하고 Base64 인코딩한 문자열
• Basic 인증은 디코딩이 가능하므로 보안 강도에 따라 SSL, TLS를 사용해 HTTPS 사용 검토 필요

15. 인증 (DIGEST)
• Digest 인증은 Basic 인증보다 보안이 강화된 인증 방식, 어떤 메시지에 대해 해시함수를 적용한 해시값을 의미
• 클라이언트는 인증 정보 없이 요청을 송신 후 응답으로 401 Unauthorized와 함께 인증 정보를 받음
요청 DELETE /test HTTP/1.1
Host : example.com
응답 HTTP/1.1 401 Unauthorized
WWW-Authenticate : Digest realm=“example.com”, nonce=“1ac421d9e
0a4k7...”, qop=“auth”, opaque=“92eb5ffee6ae2fec…”
• WWW-Authenticate 헤더의 값을 „챌린지(challenge)‟라고 부른다.

16. 인증 (DIGEST)
• „nonce‟는 모든 요청에 대해 변화하는 문자열, 서버에 의해 타임스탬프와 서버만이 알 수 있는 패스워드 조합으로 생성
• „qop‟는 „auth‟나 „auth-init‟을 지정, 클라이언트가 송신할 다이제스트의 작성법에 영향을 미침
• „auth‟의 경우 메서드와 URI로부터 다이제스트 작성
• „auth-init‟의 경우 메서드와 URI에 추가로 메시지 바디도 이용
• „opaque‟는 클라이언트에는 불투명한 문자열로, 동일 URI 공간에 대한 요청에는 공통되게 클라이언트 서버로 전송

17. 인증 (DIGEST)
• 서버로부터 인증에 필요한 정보를 얻은 클라이언트는 자신의 유저 이름과 패스워드를 사용해 다이제스트를 생성
• (1) 유저이름, realm, 패스워드를 „:‟로 연결하고, MD5 해시 값 생성
• (2) 메서드와 URI의 패스를 „:‟로 연결하고, MD5 해시값 생성
• (1)의 값, 서버로부터 얻은 nonce, 클라이언트가 nonce를 보낸 횟수, 클라이언트가 생성한 nonce, qop 값,
(2)의 값을 „:‟로 연결하고 MD5 해시값 생성하여 response 필드에 넣고 서버로 전송
DELETE /test HTTP/1.1
Host : example.com
Authorization : Digest username=“kideok”, realm=“example.com”,
nonce=“1ac421d930a…”, uri=“/test”, qop=“auth”, nc=00000001, cnonce=“90015
0983cd24…”, response=“0fde218e18…”, opaque=“92eb5ffee6ae…”

18. 인증 (BASIC과 DIGEST 장단점)
• Basic 인증과 달리 Digest 인증은 서버에 패스워드의 해시 값을 보관하며, 암호화해 전송하기 때문에 안전
• 다만 패스워드만 암호화 하기 때문에 메시지 자체는 Basic과 마찬가지로 HTTPS 검토 필요
• Basic의 경우 같은 URI 공간의 리소스는 한번 인증되면 자동으로 유저이름과 패스워드 전송 가능
• Digest의 경우 서버로부터 nonce값이 전달되지 않으면 요청시마다 401 Unauthorized 응답 필요
• Apache 등의 웹 서버에서는 Digest 인증이 옵션으로 지원하지 않을 가능성 존재

19. 인증 (WSSE)
• WSSE는 HTTP 1.1의 표준 외의 인증 방식, AtomPub 등의 웹 API 인증에 사용
• Basic, Digest를 사용하지 못할 경우 사용하기 위해 인간에 의해 책정된 인증 방식
• Digest와 동일하게 클라이언트는 인증 정보 없이 요청을 보내고 서버로부터 401 Unauthorized 응답을 받음
요청 DELETE /test HTTP/1.1
Host : example.com
응답 HTTP/1.1 401 Unauthorized
WWW-Authenticate : WSSE realm=“example.com”, profile=“UsernameToken”

20. 인증 (WSSE)
• 클라이언트는 패스워드와 자신이 준비한 nonce, 일시를 연결한 문자열에 대해 SHA-I 해시 값을 구해 Base64 인코딩
• 클라이언트는 Authorization 헤더에 „WSSE‟와 „profile=“UsernameToken”을 지정하고 X=WSSE 확장 헤
더에 패스워드 다이제스트와 nonce, 일시정보를 넣어 서버에 요청 전송
DELETE /test HTTP/1.1
authorization : WSSE profile=“UsernameToken”
X-WSSE : UsernameToken Username=“kideok”, PasswordDigest=“pkkkpksmpk
ikqqSrpK2krw==“, Nonce=“88akf2947cd…”, Create=“2013-06-15T02:19:12Z”
• 서버에서는 DB에 보관하고 있는 사용자의 패스워드를 사용해 패스워드 다이제스트를 구하고 클라이언트에서 전송된 값과 비교
하여 인증 통과

21. 캐시
• 캐시는 서버로부터 가져온 리소스를 로컬 스토리지에 저장하여 재사용하는 방법
• 리소스가 캐시 가능한지의 헤더의 Pragma, Expire, Cache-Control 헤더를 이용해 서버가 지정
• Pragma는 캐시를 사용하지 않도록 „no-cache‟라고 지정
HTTP/1.1 200 OK
Content-Type : application/xhtml+xml, charset=utf-8
Pragma : no-cache

22. 캐시
• Expires는 캐시의 유효기간을 지정
HTTP/1.1 200 OK
Content-Type : application/xhtml+xml, charset=utf-8
Expires : Sat, 15 June 2013 16:00:00 GMT
• Pragma, Expires 헤더는 HTTP 1.0이 정의한 헤더, Cache-Control은 HTTP 1.1에서 정의한 헤더로
Pragma, Expires 헤더의 기능을 완전히 대응 가능
Cache-Control : no-cache
Cache-Control : max-age : 86400

23. 캐시
• 로컬캐시를 재사용할 수 없다고 판단된 경우에도 조건부 GET을 통해 캐시를 재사용할 수 있는 가능성 존재
• 조건부 GET이란 서버 측의 캐시가 변경되었는지를 검토하는 구조
• If-Modified-Since 헤더는 특정 일시의 갱신 정보를 서버로 전송하여 비교
요청 GET /test HTTP/1.1
Host : example.com
If-Modified-Since : Sat, 15 June 2013 16:00:00 GMT
응답 HTTP/1.1 304 Not Modified
Content-Type : application/xhtml+xml, charset=utf-8
Last-Modified : Sat, 15 June 2013 16:00:00 GMT

24. 캐시
• If-None-Match 헤더는 시계를 가지고 있지 않은 서버와 밀리 초 단위로 변경할 가능성이 있는 서버에 사용
요청 GET /test HTTP/1.1
Host : example.com
If-None-Match : ab3322028
응답 HTTP/1.1 304 Not Modified
Content-Type : application/xhtml+xml, charset=utf-8
ETag : ab3322028
• If-Modified-Since 헤더는 지정한 시간 이후로 갱신되었는지를 비교, If-None-Match 헤더는 지정한 값 과 일치하는
지를 비교

25. 지속적 접속
• HTTP 1.0에서는 클라이언트가 TCP 커넥션을 생성해 요청을 송신하고 서버가 이에 응답한 후 TCP 커넥션 끊음
• HTTP 1.0에서 Keep-Alive 헤더를 사용해 TCP 커넥션을 유지했지만, HTTP 1.1에서는 Default로 구현
• 지속적 접속에서는 클라이언트가 응답을 기다리지 않고 같은 서버에 요청 송신 가능 = „파이프라인화‟
• 커넥션을 끊고 싶을 때는 Connection 헤더에 close 값을 지정
GET /test HTTP/1.1
Host : example.com
Connection : close

26. 그 밖의 HTTP 헤더
• Content-Disposition 헤더는 서버가 클라이언트에게 파일명을 제공해주기 위한 응답 헤더
예시 Content-Disposition : attachment; filename=“rest.txt”
Gmail-Firefox 3.6 (“아.txt”) Content-Disposition : attachment; filename=“?UTF-8?B?7JW…==?=”
Gmail-IE 8 (“아.txt”) Content-Disposition : attachment; filename=“%EC%95%84.txt”
• Slug 헤더는 클라이언트가 Atom의 엔트리를 POST할 때 새로 생성할 리소스의 URI 힌트 문자열을 서버에 제시
Slug : %ED%85%...%B8
• 특정 브라우져, Slug 헤더에서는 MIME의 규정에 기초한 메일 헤더가 사용하는 ASCII 문자 취급 규정 대신 조금 더 간단한 UTF-8의 %인코딩
사용