O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Http 헤더

4.459 visualizações

Publicada em

HTTP 1.1 Header

Http 헤더

  1. 1. Team-Mobs 박 기 덕HTTP 헤더
  2. 2. HTTP 헤더의 탄생• HTTP 최초 버전인 0.9에는 헤더가 없었다.• 메타데이터를 표현하기 위해 전자메일의 메시지 스펙(RFC822)의 헤더 형식을 인용해 추가• 때문에 아래와 같은 전자메일과 공통적인 헤더 부분이 다수 존재Content-TypeContent-LengthDate이외 다수 존재…• 전자메일은 한 방향으로 메시지를 요청하고 응답을 받지 않으며, HTTP는 한번의 통신으로 요청/응답을 처리
  3. 3. 날짜와 시간이용하는 메시지 헤더 의미요청과 응답 Date 메시지를 생성한 일시요청 If-Modified-Since 조건부 GET으로 리소스의 갱신일시를 지정할 때 이용If-Unmodified-Since 조건부 PUT, 조건부 DELETE로 리소스의 갱신일시를 지정할 때 이용응답 Expires 응답을 캐시 할 수 있는 기한Last-Modified 리소스를 마지막으로 갱신한 일시Retry-After 다시 요청을 전송할 수 있는 일시의 기준• 그리니치 표준시(GMT)를 사용해 날짜와 시간 표시
  4. 4. MIME 미디어 타입• 메시지를 주고 받는 리소스 표현의 종류를 지정• 전자메일의 헤더에서 인용한 스펙으로 HTTP에서는 Content-Type 등 몇 개의 헤더만을 이용• Content-Type• 메시지의 바디 내용이 어떠한 종류인가를 미디어 타입으로 표시Content-Type : application/xhtml + xml; charset = utf-8• 위의 예에서 application이 타입, xhtml + xml이 서브타입• 타입의 종류는 RFC 2045(메시지 포맷), RFC 2046(미디어 타입) 에서 정의된 타입만 사용, 서브타입의 종류는 비교적자유롭게 생성 가능
  5. 5. MIME 미디어 타입 (TYPE)타입 의미 예text 사람이 읽고 직접 이해할 수 있는 텍스트 text/plainimage 그림 데이터 image/jpegaudio 음성 데이터 audio/mpegvideo 동영상 데이터 video/mp4application 그 밖의 데이터 application/pdfmultipart 복수의 데이터로 이루어진 복합 데이터 multipart/relatedmessage 전자메일 메시지 message/rfc822model 복수 차원으로 구성하는 모델 데이터 model/vrmlexample 예시용 example/foo-bar
  6. 6. MIME 미디어 타입(SUB TYPE)타입/서브타입 의미 타입/서브타입 의미text/plain 플레인 텍스트 application/atomsvc+xml Atom의 서비스 문서text/csv CSV형식 텍스트 application/atomcat+xml Atom의 카테고리 문서text/css CSS형식의 스타일 시트 application/javascript JavaScripttext/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. 7. MIME 미디어 타입• 미디어 타입은 charset 파라미터를 가질 수 있다.• charset은 생략 가능하지만 text 타입의 경우 주의가 필요• text타입의 디폴트 문자 이코딩은 ISO 8859-1로 정의되기 때문에 생략 시 한글 텍스트가 깨질 수 있다.• XML 문서 자체에서 인코딩 방식을 선언해도 text타입은 Content-Type 헤더의 charset 파라미터를 우선• text타입의 경우 반드시 charset 파라미터를 붙여야 한다.• 또한 text/html 사용을 자제하고, application/xml 혹은 application/xhtml+xml 사용을 권고
  8. 8. MIME 미디어 타입• XML이 선언한 문자 인코딩 지정을 무시하는 예HTTP/1.1 200 OKContent-Type : text/html<?xml version=“1.0” encoding=“utf-8”?><test>한글 텍스트</test>• 바르게 문자 인코딩을 지정한 예HTTP/1.1 200 OKcontent-Type : application/xml; charset=utf-8<?xml version=“1.0” encoding=“utf-8”?><test>한글 텍스트</test>
  9. 9. 언어 태그• Content-Language 헤더는 리소스 표현의 자연언어를 지정Content-Language : ko-KR• 언어 태그의 „-‟ 왼편에는 ISO 639(언어의 약자)가 정의한 언어코드• 언어 태그의 „-‟ 오른편에는 ISO 3166(지역의 약자)가 정의한 지역코드• ISO 639, ISO 3166에는 2글자의 약자와 3글자의 약자가 있는데 보통 2글자의 약자를 사용
  10. 10. 콘텐트 네고시에이션• 클라이언트와 교섭해서 미디어 타입을 정함• 클라이언트가 자신이 처리할 수 있는 미디어 타입을 서버에게 전달할 경우 Accept 헤더를 이용Accept : text/html, application/xhtml+xml, application/xml; q=0.9, */*; q=0.8• 클라이언트가 지정한 미디어 타입을 서버가 대응하지 않는다면 406 Not Acceptable 반환요청 GET /test HTTP/1.1Host : example.comAccept : application/xml, application/msword;q=0.9응답 HTTP/1.1 406 Not Acceptable
  11. 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. 12. CONTEN-LENGTH와 청크(CHUNK) 전송• 메시지가 바디를 가지고 있을 때, 기본적으로 Content-Length 헤더를 이용, 사이즈를 10진수의 바이트로 표현Content-Length : 5583• 동적으로 생성하여 전송하는 경우 전체 파일사이즈가 정해지지 않아도 전송 가능Transger-Encoding : chunked• 다음과 같이 분할하여 전송 가능, Chunk의 구분을 위하여 마지막에는 반드시 길이가 0인 Chunk와 빈줄을 붙임POST /test HTTP/1.1 10Host : example.com The brow fox ju10Transfer-Encoding : chunked mps quickly overContent-Type : text/plain; charset=utf-8 ethe lazy dog.0(빈 공백 삽입)
  13. 13. 인증• HTTP 1.1이 규정하는 Basic 인증과 Digest 인증, 웹 API에서 HTTP 인증의 확장으로 WSSE 사용• 리소스에 엑세스 제어가 걸려있을 때, 스테이터스 코드 401 Unauthorized, WWW-Authenticate 헤더 이용요청 DELETE /test HTTP/1.1Host : example.com응답 HTTP/1.1 401 UnauthorizedWWW-Authenticate : Basic realm=“example.com”• realm은 URI공간의 이름, URI공간은 패스 이하를 가르킴
  14. 14. 인증 (BASIC)• Basic 인증은 유저 이름과 패스워드에 의한 인증 방식DELETE /test HTTP/1.1Host : example.comAuthorization : Basic dXNlcjpwYXNzd29yZA==• Authorization 헤더의 내용은 유저 이름과 패스워드를 „:‟로 연결하고 Base64 인코딩한 문자열• Basic 인증은 디코딩이 가능하므로 보안 강도에 따라 SSL, TLS를 사용해 HTTPS 사용 검토 필요
  15. 15. 인증 (DIGEST)• Digest 인증은 Basic 인증보다 보안이 강화된 인증 방식, 어떤 메시지에 대해 해시함수를 적용한 해시값을 의미• 클라이언트는 인증 정보 없이 요청을 송신 후 응답으로 401 Unauthorized와 함께 인증 정보를 받음요청 DELETE /test HTTP/1.1Host : example.com응답 HTTP/1.1 401 UnauthorizedWWW-Authenticate : Digest realm=“example.com”, nonce=“1ac421d9e0a4k7...”, qop=“auth”, opaque=“92eb5ffee6ae2fec…”• WWW-Authenticate 헤더의 값을 „챌린지(challenge)‟라고 부른다.
  16. 16. 인증 (DIGEST)• „nonce‟는 모든 요청에 대해 변화하는 문자열, 서버에 의해 타임스탬프와 서버만이 알 수 있는 패스워드 조합으로 생성• „qop‟는 „auth‟나 „auth-init‟을 지정, 클라이언트가 송신할 다이제스트의 작성법에 영향을 미침• „auth‟의 경우 메서드와 URI로부터 다이제스트 작성• „auth-init‟의 경우 메서드와 URI에 추가로 메시지 바디도 이용• „opaque‟는 클라이언트에는 불투명한 문자열로, 동일 URI 공간에 대한 요청에는 공통되게 클라이언트 서버로 전송
  17. 17. 인증 (DIGEST)• 서버로부터 인증에 필요한 정보를 얻은 클라이언트는 자신의 유저 이름과 패스워드를 사용해 다이제스트를 생성• (1) 유저이름, realm, 패스워드를 „:‟로 연결하고, MD5 해시 값 생성• (2) 메서드와 URI의 패스를 „:‟로 연결하고, MD5 해시값 생성• (1)의 값, 서버로부터 얻은 nonce, 클라이언트가 nonce를 보낸 횟수, 클라이언트가 생성한 nonce, qop 값,(2)의 값을 „:‟로 연결하고 MD5 해시값 생성하여 response 필드에 넣고 서버로 전송DELETE /test HTTP/1.1Host : example.comAuthorization : Digest username=“kideok”, realm=“example.com”,nonce=“1ac421d930a…”, uri=“/test”, qop=“auth”, nc=00000001, cnonce=“900150983cd24…”, response=“0fde218e18…”, opaque=“92eb5ffee6ae…”
  18. 18. 인증 (BASIC과 DIGEST 장단점)• Basic 인증과 달리 Digest 인증은 서버에 패스워드의 해시 값을 보관하며, 암호화해 전송하기 때문에 안전• 다만 패스워드만 암호화 하기 때문에 메시지 자체는 Basic과 마찬가지로 HTTPS 검토 필요• Basic의 경우 같은 URI 공간의 리소스는 한번 인증되면 자동으로 유저이름과 패스워드 전송 가능• Digest의 경우 서버로부터 nonce값이 전달되지 않으면 요청시마다 401 Unauthorized 응답 필요• Apache 등의 웹 서버에서는 Digest 인증이 옵션으로 지원하지 않을 가능성 존재
  19. 19. 인증 (WSSE)• WSSE는 HTTP 1.1의 표준 외의 인증 방식, AtomPub 등의 웹 API 인증에 사용• Basic, Digest를 사용하지 못할 경우 사용하기 위해 인간에 의해 책정된 인증 방식• Digest와 동일하게 클라이언트는 인증 정보 없이 요청을 보내고 서버로부터 401 Unauthorized 응답을 받음요청 DELETE /test HTTP/1.1Host : example.com응답 HTTP/1.1 401 UnauthorizedWWW-Authenticate : WSSE realm=“example.com”, profile=“UsernameToken”
  20. 20. 인증 (WSSE)• 클라이언트는 패스워드와 자신이 준비한 nonce, 일시를 연결한 문자열에 대해 SHA-I 해시 값을 구해 Base64 인코딩• 클라이언트는 Authorization 헤더에 „WSSE‟와 „profile=“UsernameToken”을 지정하고 X=WSSE 확장 헤더에 패스워드 다이제스트와 nonce, 일시정보를 넣어 서버에 요청 전송DELETE /test HTTP/1.1authorization : WSSE profile=“UsernameToken”X-WSSE : UsernameToken Username=“kideok”, PasswordDigest=“pkkkpksmpkikqqSrpK2krw==“, Nonce=“88akf2947cd…”, Create=“2013-06-15T02:19:12Z”• 서버에서는 DB에 보관하고 있는 사용자의 패스워드를 사용해 패스워드 다이제스트를 구하고 클라이언트에서 전송된 값과 비교하여 인증 통과
  21. 21. 캐시• 캐시는 서버로부터 가져온 리소스를 로컬 스토리지에 저장하여 재사용하는 방법• 리소스가 캐시 가능한지의 헤더의 Pragma, Expire, Cache-Control 헤더를 이용해 서버가 지정• Pragma는 캐시를 사용하지 않도록 „no-cache‟라고 지정HTTP/1.1 200 OKContent-Type : application/xhtml+xml, charset=utf-8Pragma : no-cache
  22. 22. 캐시• Expires는 캐시의 유효기간을 지정HTTP/1.1 200 OKContent-Type : application/xhtml+xml, charset=utf-8Expires : Sat, 15 June 2013 16:00:00 GMT• Pragma, Expires 헤더는 HTTP 1.0이 정의한 헤더, Cache-Control은 HTTP 1.1에서 정의한 헤더로Pragma, Expires 헤더의 기능을 완전히 대응 가능Cache-Control : no-cacheCache-Control : max-age : 86400
  23. 23. 캐시• 로컬캐시를 재사용할 수 없다고 판단된 경우에도 조건부 GET을 통해 캐시를 재사용할 수 있는 가능성 존재• 조건부 GET이란 서버 측의 캐시가 변경되었는지를 검토하는 구조• If-Modified-Since 헤더는 특정 일시의 갱신 정보를 서버로 전송하여 비교요청 GET /test HTTP/1.1Host : example.comIf-Modified-Since : Sat, 15 June 2013 16:00:00 GMT응답 HTTP/1.1 304 Not ModifiedContent-Type : application/xhtml+xml, charset=utf-8Last-Modified : Sat, 15 June 2013 16:00:00 GMT
  24. 24. 캐시• If-None-Match 헤더는 시계를 가지고 있지 않은 서버와 밀리 초 단위로 변경할 가능성이 있는 서버에 사용요청 GET /test HTTP/1.1Host : example.comIf-None-Match : ab3322028응답 HTTP/1.1 304 Not ModifiedContent-Type : application/xhtml+xml, charset=utf-8ETag : ab3322028• If-Modified-Since 헤더는 지정한 시간 이후로 갱신되었는지를 비교, If-None-Match 헤더는 지정한 값 과 일치하는지를 비교
  25. 25. 지속적 접속• HTTP 1.0에서는 클라이언트가 TCP 커넥션을 생성해 요청을 송신하고 서버가 이에 응답한 후 TCP 커넥션 끊음• HTTP 1.0에서 Keep-Alive 헤더를 사용해 TCP 커넥션을 유지했지만, HTTP 1.1에서는 Default로 구현• 지속적 접속에서는 클라이언트가 응답을 기다리지 않고 같은 서버에 요청 송신 가능 = „파이프라인화‟• 커넥션을 끊고 싶을 때는 Connection 헤더에 close 값을 지정GET /test HTTP/1.1Host : example.comConnection : close
  26. 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의 %인코딩사용

×