HTTP Header 분석

HTTP 헤더는 클라이언트와 서버 사이에서 모든 종류의 정보를 전송하는데 이용되며 크게 4가지로 분류할 수 있다.
General - 클라이언트, 서버 또는 HTTP와 관계된 정보
Request - 문서 양식과 서버의 매개 변수들
Response - 응답을 보내는 서버에 대한 정보
Entitiy - 클라이언트와 서버 사이에 전송되는 데이터에 대한 정보
HTTP메시지에 있는 모든 헤더는 헤더 이름을 포함하여 콜론, 공백, 헤더의 값 순으로 구성된다. 헤더 이름은 대소문자를 구별하지 않는다. 또한 헤더의 값은 적어도 하나의 공백이나 탭 문자를 각행에 붙임으로써 여러 줄로 확장하여 쓸 수 있다.
일반 헤더와 ENTITY헤더는 서버와 클라이언트 모두 동일하다.

<<일반 헤더>>
일반 헤더는 클라이언트의 요청과 서버의 응답 양쪽에서 사용될 수있다.
일반 헤더는 다음과 같은 내용을 가지고 있다.
- Cache-Control
Cache-control:  directives
쉼표로 구분된 목록에 캐싱 지시문을 지정

캐시 요청 지시문
ㄱ. no-cache              캐시 하지 않는다.
ㄴ. no-store              신속히 넘긴 후에 정보를 제거한다.
ㄷ. max-age = seconds     seconds에 지정한 것보다 오래된 응답은 보내지 않는다.
ㄹ. max-stale [=seconds]  만료된 데이터를 보낸다. 만약 seconds가 지정되어 있다면 지정한 숫자보다 적은 만료된 데이터를 보낸다.
ㅁ. min-fresh = seconds   명시된 seconds의 수 이후의 변경된 새 데이터만 보낸다.
ㅂ. only-if-cached        새로운 데이터를 검색하지 않고 캐시에 있는 데이터만 반환한다.

캐시 응답 지시문
ㄱ. public                어떠한 캐시라도 캐시할수 있다.
ㄴ. private               공유된 캐시는 캐시하지 않는다.
ㄷ. no-cache              캐시하지 않는다.
ㄹ. no-transform          데이터를 변환하지 않는다.
ㅁ. must-revalidate       클라이언트는 데이터를 재확인 해야 한다.
ㅂ. proxy-revalidate      개인적인 클라이언트 캐시를 제외하고 데이터를 재확인 해야한다.
ㅅ. max-age=seconds       문서는 지정된 seconds만큼만 변화가 없는 상태라고 생각

Connection
Connection:  options
options에서는 연결을 위해 지정하는데 프록시 서버에 의한 연결은 포함하지 않는다. close연결 옵션은 클라이언트나 서버 둘 중 하나가 연결을 해제하기를 원한다는 것을 알린다.

Date
Date:  dateformat
현재의 날짜와 시간을 표시한다.
예) Mon, 11 May 2000 07:45:00 GMT
때로는 이전과 호환을 위해 RFC-850과 ANSI C asctime() 도 사용할 수 있다.
Monday, 11-May-98 07:45:00 GMT
Mon May 11 07:45:00 2000
단 년도 항목에 2자리를 사용으로 인한 문제가 발생할 수 있다.

MIME-Version
MIME-Version:  version
HTTP 트랜젝션에서 사용되는 MIME(RFC-2045[7])의 버전을 말한다.
메시지의 ENTITY몸체가 MIME를 따르지 않으면 이 헤더는 생략될 수 있다. 만약 틀랜잭션에서 MIME-encoded데이터를 호출하지만 이 헤더가 삭제되었다면 디폴트로 1.0을 사용한다.

Progma
Pragma: no-cache
프록시 시스템에 대한 지시문을 말한다. 이 헤더는 목표가 되는 서버에서는 무시된다.
HTTP는 이 헤더를 위해 no-cache라는 지시어만 정의 한다. HTTP 1.0에서, 이 것은 그 로컬 캐시 대신 서버로부터의 문서를 요구하도록 프록시 서버에 명령한다.
단, HTTP1.1은 Cache Control:no-cache를 주로 사용한다.

Transfer-Encoding
Transfer-Encoding:  encoding_type
안전한 전송을 위해 메시지 본체에 어떤 종류의 변환이 적용이 됐는지 나태낸다.

Upgrade
Upgrade:  protocol/version
우선하는 프로토콜을 명시한다. 응답 코드 101 Switching Protocols과 연결하여 사용된다.
예) Upgrade: HTTP/1.2

Via
Via:  protocol host   [comment]…
게이트웨이와 프록시에 의해 사용되어 클라이언트와 서버 간의 트랜잭션을 처리하는 프로토콜과 호스트를 표시한다.

<<클라이언트 요청 헤더>>
Accept
Accept:  type/subtype [; q=qvalue]
클라이언트가 우선적으로 받아들이는 미디어 형을 명시한다. 여러 개의 미디어 형을 쉼표로 구분해서 나열할 수있다. 옵션인 qbalue는 받는 형태의 수준 순서로써 0 에서 1까지 나타낸다.

Accept-Charaset
Accept-Charset: character_set [;q=qvalue]
클라이언트가 우선하는 문자 세트를 지정한다. 여러 개의 문자 세트는 쉼표로 구분하여 나열한다. 옵션인 qvalue는 우선하지 않는 문자 세트의 수준 순서로 0 에서 1까지 나타낸다.

Accept-Encoding
Accept-Encoding:  endoding_types
compress 또는 gzip과 같은 클라이언트가 받아들일 수 있는 인코딩 방식을 지정한다. 여러 개의 인코딩 방식을 쉼표로 구분하여 나열한다. 만약 인코딩 형태를 지정하지 않으면 어떤 형태도 클라이언트에게 받아들여지지 않는다.

Accept-Language
Accept-Language: language [; q=qvalue]
클라이언트가 우선적으로 지원하는 언어를 지정한다. 쉼표로 구분해서 여러 개의 언어를 지정할 수 있다. 옵션인 qvalue는 우선하지 않는 언어 순서로 0에서 1까지로 나타낸다. 언어는 두문자로 축약해서 쓴다.(예)en, fr, kr 등

Authorization
Authorization: scheme credentials
URI에 클라이언트가 데이터에 접근할 수 있는 권한을 제공한다. 요청된 문서가 권한을 요구하면 서버는 요구된 권한의 유형을 설명하는 WWW-Authenticate헤더를 반환한다. 그리고 나서 클라이언트는 적당한 권한 정보를 요청할 때마다 이것을 반복한다.
HTTP에 일반적으로 사용된 권한 계획은 BASIC이며, BASIC방식에서는 권한을 인증하기 위해 base64로 인코딩된 username:password 형태를 따른다. 예를 들면, 사용 자명이 ‘webmaster’ 이고 패스워드가‘zrma4v’라면 authorization 헤더는 이것을 다음과 같이 보이게 한다.
Authorization: BASIC d2VibWFzdGVyOnpycW1hNHY=
이것의 디코딩 값은 webmaster : zrma4v이다

Cookie
Cookie: name=value
URL을 위해 저장된 정보의 이름=값을 포함한다. 여러 개의 쿠키는 세미콜론으로 구분하여 나열된다. 넷스키이프도 쿠키를 지원한다. HTTP표준에는 포함되어 있지 않다.

From
From: email_address
현재 사용하고 있는 클라이언트의 전자 우편 주소를 반환한다.

Host
Host: hostname[:port]
호스트의 이름과 URI의 port번호를 지정한다. 클라이언트는 HTTP1.1에 반드시 이정보를 공급해야 하는데 이것은 여러 개의 호스트명이 갖는 애매한 URL을 쉽게 구별하는 데 도움이 된다.

If-Modified-Since
If-Modified-Since: date
헤더의 값으로 주어진 날짜 이후 수정이 되었다면 URI데이터를 보낸다는 것을 명시한다. 이것은 클라이언트 측 캐시에 대해 유용하다. 만약 문서가 수정되지 않았다면 서버는 304코드를 반환하여 클라이언트에게 로컬에 있는 사본을 보여준다. 단 지정한 날짜는 Date헤더 아래에 설명된 형식을 따라야 한다.

If-Match
If-Match: entity_tag
조건적으로 요청하는 것으로 주어진 ENTITY태그와 매치된다. *기호는 어떠한 ENTITY와도 매치되며, ENTITY가 존재해야만 트랜잭션이 계속된다.

If-None-Match
If-None-Match: entity_tag
조건적으로 요청하는 것으로 주어진 엔티티 태그와 어떠한 것도 매치되지 않는다.
*기호는 어떠한 엔티티와도 매치되며 엔티티가 존재하지 않아야만 트랜잭션이 계속된다.

If-Range
If-Range: entity_tag | date
조건적으로 요청하는 것으로 실체의 일부가 변하지 않았는데 찾을 수 없고, 그것이 실체의 전부를 나타낸다. Range헤더와 함께 사용되어야 한다. ENTITY 태그나 날짜 둘 중 하나는 이미 주어진 실체의 일부분을 식별할 수 있다.

If-Unmodified-Since
If-Unmodified-Since: date
주어진 날짜 이후로 수정되지 않았다면 URI데이터를 보내도록 지정한다. 지정한 날짜는 Date헤더 아래에 설명된 형식을 따라야 한다.

Max-Forwards
Max-Forwards: n
요청을 전달한 프록시나 게이트 웨이의 개수를 제한한다. TRACE 메소드와 함께 사용하여 디버깅에 유용하며, 무한 루프를 피할 수 있다.

Proxy-Authorization
Proxy-Authorization: credentials
클라이언트가 권한을 요구하는 프록시에 대해 자신을 식별하기 위해 사용한다.

Range
Range: bytes= n-m
문서가 요구하는 부분적인 범위를 명시한다. 여러 개의 범위는 세미콜론으로 구분하여 나열한다. 만약 쉼표로 구별된 바이트 범위인 첫번째 숫자가 없다면 범위는 문서의 끝에서부터 없어진다고 가정한다. 만일 두번째 숫자가 없다면 범위는 끝에서 n바이트까지이다. 첫번째 바이트는 0바이트이다.

Referer
Referer: url
요청된 URI를 참조하는 문서의 URI에 전달한다.

User-Agent
User-Agent: string
클라이언트 프로그램에 대한 식별 가능한 정보를 준다.

<<서버 응답 헤더>>
Accept-Ranges
Accept-Ranges: bytes|none
URI를 위한 요청 범위의 승인을 나타내며 또는 받아들인 요청의 범위가 없을 경우 none을 지정한다. 범위의 단위는 byte이다.

Age
Age: seconds
seconds에 문서의 나이를 지시한다.

Proxy-Authenticate
Proxy-Authenticate: scheme realm
확인 계획과 이URI와 그 현재의 연결에 대해 프록시에 대한 적용할 수 있는 매개변수를 나타낸다. 응답으로 407을 사용한다.

Retry-After
Retry-After: dateseconds
응답코드 503(Service Uncavailable)과 함께 사용된다. 정수나 GMT 날짜와 시간(Date 헤더 형태를 설명)둘 중 하나를 포함한다. 만일 값이 정수이면 seconds의 숫자로 해석하여 요청이 발생한 후 지정한 seconds만큼 기다린다.
예) Retry-After: 3500
Retry-After: Fri, 17 May 1999 12:24:17 GMT

Server
Server: string
서버의 이름과 버전 번호를 포함한다.
예) Server: NCSA/1.3

Set-Cookie
Set-Cookie: name=value [; option ]
U R L을 위해 보유한 정보의 이름/값 쌍을 포함한다. 넷스케이프 쿠키를 지원하기 위
한 것으로 HTTP 표준에는 포함되어 있지 않다.
옵션의 예)
expires=date
지정된 날짜가 지나면 쿠키가 유효하지 않게 된다.
path=pathname
쿠키가 유효한URL 범위
domain=domain_name
쿠키가 유효한 도메인명의 범위
secure
보안이 적용된 연결에서만 쿠키를 반환한다.
HttpOnly
Cookie에서만 사용하게 제한(XSS 차단을 위해서)

Vary
Vary: *| headers
엔티티가 다중 자원을 가지고 있으므로 요청한 헤더를 지정한 목록이 상황에 따라 변할 수 있다는 것을 지정한다. 여러 개의 헤더는 세미콜론으로 구분하여 나열한다.
*기호는 요청한 헤더가 반환되는 문서에 영향을 미칠 수도 있는 다른 요인을 의미한다.

Warning
Warning: code host [ :port] string
프록시 캐싱에서 사용하기 위한 상태 코드의 추가 정보를 나타낸다. host필드는 이름 또는 서버 호스트의 익명을 포함하며, 선택적으로 포트 번호를 포함한다. 두 자리 경고 코드와 그것을 설명하는 문자열은 다음과 같다.
10 Response is stale
응답 데이터는 오래된 것으로 알려져 있다.
11 Revalidation failed
응답 데이터는 오래된 것으로 알려져 있으며 그 이유는 프록시가 데이터를 재검증하는 데 실패했기 때문이다.
12 Disconnected operation
캐시가 네트워크로부터 연결되지 않았다.
13 Heuristic expiration
데이터는2 4시간 이상 된 것이며, 캐시는2 4시간 보다 더 이전에 만들어진 것을 사용한다.
14 Transformation applied
프록시는Content-Encoding이나 Content-Type 헤더에 명시한 대로 인코딩이나 문서의 미디어 형을 변경시켰다.
99 Miscellaneous warning
임의의 정보가 클라이언트에게 접속되거나 나타났다.

WWW-Authenticate
WWW-Authenticate: scheme realm
401(Unauthorized) 응답 코드와 함께 사용된다. 요청된 URI에서 클라이언트로부터 요청된 권한의 범위와 권한의 계획을 명시한다. 많은 다른 권한 범위는 서버에 존재한다. 일반적인 권한 계획은 BASIC이며 사용자명과 패스워드를 요구한다.
예) WWW-Authenticate: BASIC realm="admin"

<<ENTITY Header>>
Allow
Allow: methods
지정한 URI에서 허락하는 메소드를 쉼표로 구분된 목록을 포함한다. 요청된 정보에 유용한 메소드들을 클라이언트에게 알리는 코드 405(Method Not Allow)를 서버 응답에 사용한다.

Content-Encoding
Content-Encoding: encoding_schemes
엔티티 몸체를 전송할 때 사용할 인코딩 체계(scheme)를 지정한다. 값으로는gzip(또는 x-gzip)과 compress(또는 x-compress)를 사용할 수 있다. 만약 여러 개의 인코딩 체계(쉼표로 구별한 목록 안에)가 지정되어 있다면 소스 데이터에 적용한 명령을 나열해야 한다.

Content-Language
Content-Language: languages
전송될 엔티티 몸체에서 의도하는 언어를 지정한다. 언어는 두 자리 숫자 코드로 나타낸다.(예, en, kr 등)

Content-Length
Content-Length: n
이 헤더는 전송된 엔티티 몸체가 가진 데이터의 길이(byte 단위로)를 지정한다. 어떤요청은 동적인 성질을 가질 수 있기 때문에 컨텐츠의 길이를 알 수 없을 경우도 있고, 이 경우에는 이 헤더를 제거한다.

Content-Location
Content-Location: uri
엔티티에 대한 URI를 제공한다. 이 경우 문서가 독립적으로 접근 가능한 위치에 다중 엔티티를 갖고 있을 수 있다. U R I는 절대 혹은 상대 경로로 지정할 수 있다.

Content-MD5
Content-MD5: digest
인수한 메시지의 완전성을 검사하기 위해 엔티티의 MD5 다이제스트를 제공한다.

Content-Range
Content-Range: bytes n-m/length
수반하는 엔티티 몸체 일부에 삽입되며, 전체 엔티티 몸체의 크기를 지정한다.
예)Content-Range: bytes 6143-7166/15339

Content-Transfer-Encoding
Content-Transfer-Encoding: scheme
네트워크에 전달되는 엔티티 몸체에 적용되는 어떤 변화를 지정한다. 일반적인 값으로는 7bit, 8bit, binary, base64, 그리고 quoted-printable이 있다.

Content-Type
Content-Type: type/subtype
엔티티 몸체의 미디어 형과 부미디어 형을 설명한다. 이는 같은 값을 클라이언트의Accept 헤더로 사용하며, 서버는 그 클라이언트가 우선적으로 지원하는 포맷 양식에 따르는 미디어 형을 반환해야 한다.

ETag
ETag: entity_tag
If-Match와 If-None-Match 요청 헤더를 위한 태그를 정의한다.

Expires
Expires: date
문서가 변경될 수도 있을 때의 시간 또는 그것의 정보가 유효하지 않을 때의 시간을명시한다. 그 시간 이후, 문서는 변경 또는 삭제되거나 그렇지 않을 수 있다. 값은 Date 헤더에서 설명한 것과 같은 유효한 형태의 날짜와 시간이다.

Last-Modified
Last-Modified: date
지정한 URI가 마지막으로 변경된 때를 명시한다. 값은Date 헤더에 설명한 것과 같은 유효한 형태의 날짜와 시간이다.

Location
Location: uri
문서의 새로운 위치를 지정한다. 일반적으로 응답 코드 201(Created), 301(MovedPerm anently), 또는302(Moved Temporarily)와 함께 사용된다. 주어진URI는 절대 주소로 지정해야 한다.

쿠키(Cookie)
항구적인 상태에 있는 클라이언트측 쿠키는 넷스케이프 네비게이터에서 소개한 것으로, 서버가 클라이언트의 장치에서 클라이언트가 지정한 정보를 저장할 수 있게 하기 위한 것이다. 서버는 클라이언트에 의해 다시 특정한 페이지나 서버에 접근할 때 그 정보를 이용할 수 있다. 쿠키 작동 형태는 서버가 각 클라이언트에 보내는 페이지를 개별화할 수 있도록 해주거나 사이트의 다양한 페이지들을 브라우징할 때 클라이언트가 선택했던 것들을 기억할 수 있게 해준다. 따라서 서버측에서 복잡한 CGI나 데이터베이스 시스템을 사용하지 않아도 된다.
쿠키는 다음과 같은 방법으로 작동한다. CGI 프로그램은 새로운 사용자를 식별할 때,서버가 클라이언트의 입력에서 조금씩 모아둔 정보와 그 사용자에 대한 식별자를 포함에 부가 헤더를 추가한다. 이 헤더는 클라이언트의 쿠키 파일에 사용자의 쿠키정보를 추가하라고 쿠키를 사용할 수 있는 브라우저에 알린다. 그러면, 웹 브라우저 URL의 모든 요청은 기타 헤더의 요청에 그 쿠키 정보를 포함시킬 것이며, CGI 프로그램은 특정한 사용자에게 맞추어진 문서를 보여줄 때 이 정보를 사용한다.
쿠키는 클라이언트의 하드 드라이브에 저장되므로 정보는 웹 브라우저가 닫히고 다시 열어도 남아 있다.

Set-Cookie 응답 헤더
사용자가 처음으로 사이트나 페이지를 방문하면 쿠키가 생성된다. CGI 프로그램은 사용자 요청을 받으면 이전의 쿠키 정보를 검색한다. 만약 쿠키가 없다면 Set-Cookie 헤더를 포함하는 응답을 보낸다. 이 헤더에는 클라이언트에 대해 유지하고자 하는 정보를 담고 있는 이름/값 으로 포함되어 있다. 헤더에 다른 선택 필드들도 포함시킬 수 있다.
Set-Cookie 헤더는 다음과 같은 구문을 사용한다.
Set-Cookie: name=value; expires=date;
path=pathname; domain=domain-name; secure
여러 개의 Set-Cookie 헤더는 서버 응답에 포함될 수 있다. ‘이름=값’으로 이루어진쌍은 이 헤더에 요구되는 유일한 속성이며, 처음에 와야 한다. 그 다음 속성들은 순서 없이 사용할 수 있고 다음과 같이 정의한다.
name=value
이름과 값 모두에 세미콜론, 공백(space), 또는 탭(tab)을 포함하지 않는 문자열을 지정한다. 스크립트를 다룰 준비가 되는 한, 실체가 그 이름이나 값에서URL 인코딩과 같은 인코딩을 요구한다면 사용할 수 있다.
expires=date
이 속성으로 쿠키의 유효 기간이 끝나는 날짜를 설정한다. 날짜의 형식은 표준적인 방법을 따르지 않고 다음과 같이 지정한다.
Wednesday, 01-Sep-96 00:00:00 GMT
이 날짜가 지나면 쿠키의 유효성이 만료하여 웹 브라우저가 더 이상 쿠키를 보내지 않는다. 만료일 표시에는 G M T(Greenwich Mean Time)만 사용된다. 만료일을 지정하지 않으면 쿠키는 현재 세션에서만 사용된다.
path=pathname
path 속성은 쿠키가 유효한 URL의 범위를 제공한다. 예를 들어, 경로명을/ pub라고 설정하면 /pub에 있는 /pub/docs나 /pub/images와 같은 하위 수준의 URL에도 쿠키를 보낸다. ‘/’의 pathname을 나타낸다면 쿠키가 지원하는 사이트의 모든 URL에 쿠키를 사용할 것이라는 뜻이다. path 속성이 없다면 쿠키는 URL에 지원하는 곳에서만 유효하다는 것을 뜻한다.
domain=domain-name
이 속성은 쿠키가 반환되는 범위의 도메인 이름을 지정한 것이다. domain-name에는 적어도 두 개의 점(.)이 포함되어 있어야 한다. 예를 들면,  .naver.com이라는 값은 www.naver.com와 cafe.naver.com, 그리고 기타 다른 naver.com 도메인을 갖는 서버 전체를 포괄한다.
secure
이 속성은 보안이 되는 연결(SHTTP와 SSL을 통한)에서만 쿠키를 반환한다는 것을 뜻한다. 이 속성이 없으면 쿠키는 연결에 상관없이 항상 반환된다.

<<쿠키 요청 헤더>>
웹 브라우저는 매번 웹 페이지로 가서 URL을 위해 저장된 쿠키에 대한 쿠키 파일이있는지 검사한다. 파일이 있으면 웹 브라우저는 요청에 쿠키의‘이름=값’쌍을 포함하는 Cookie 헤더를 포함시킨다.
Cookie: name1=value1;name2=value2;…
쿠키 파일 안에 반환된 쿠키가 여러 개의 항목으로 구성되어 있다면, 경로명 범위와도메인의 범위로 구성한다. 다음 헤더에 같은 사이트에 대해 두 개의 쿠키가 설정되어 있는 예이다.
Set-Cookie: AbcBook=book; path=/
Set-Cookie: AbcBook=Bitems; path=/books
브라우저가 /books 경로에 있는 사이트의 한 페이지를 요청하면, 그것을 반환한다.
Cookie: AbcBook=Bitems; AbcBook=Bitems
양쪽 항목이 같은 이름을 공유하지만, 그것은 별개의 쿠키이며, 양쪽 다 /books 같은 특정한 URL에 적용된다. 쿠키가 반환될 때, 웹 브라우저는 매치 여부를 따져 가장 정확한 경로명이나 도메인을 먼저 반환한다.
Cookie 헤더를 만나면 많은 서버들은 HTTP_COOKIE 환경 변수를 사용하는CGI 프로
그램으로 헤더의 값을 전달한다.
또한 쿠키들의 개수와 크기에 대한 제약이 있다.
- 클라이언트는 합쳐서 적어도 300개의 쿠키를 지원할 수 있어야 한다. 서버는 사
용자가 더 이상 저장하는 것을 기대해서는 안 된다.
- 각 쿠키(이름과 값을 조합해서)의 크기는 4KB를 넘어서는 안 된다.
- 각각의 서버 또는 도메인은 최대 20개의 쿠키를 지원한다. 이 제약 사항은 각기 지정한 서버 또는 도메인에 적용되므로 www.naver.com에서 20개를 저장할 수 있고 cafe.naver.com에서도 20개가 가능하며, 쿠키들의 이름 전체를 각기 명시 할 수 있다.

하지만 문제는 헤더와 관련된 프록시 서버에서 일어난다. 페이지가 캐시되거나 수정되지 않았을지라도, Set-Cookie와 Cookie 헤더 모두는 프록시를 통해 전파되어야 한다(If-Modified-Since 조건에 따라서). 또한 Set-Cookie 헤더는 프록시에 의해 결코 캐시 되어서는 안 된다.

GZIP
GZip 은 국제 표준으로 등록된 압축 포멧으로, 해당 표준을 준수하는 모든 브라우저에서 GZip 및 Deflate 형식의 압축 방식을 이용하여 웹 페이지에 대한 크기를 줄여서 속도개선에 뛰어난 효과를 볼 수 있다.
HTTP 헤더의 Accept-Encoding라는 sent header를 통해 전달하고 있으며, 다음 HTTP 헤더에서 ‘Accept-Encoding’ 항목과 같이 gzip, deflate중 TOPSPEEDer™에서 수용하는 압축 포멧인, ‘gzip’을 지원할 경우 해당 기능을 사용할 수 있다.
Response 헤더에 'Content-Encoding: gzip'가 포함되어 응답이 왔다면, gzip으로 압축된 것이며 다음과 같이 확인할 수 있다.

<그림1> ‘Accept-Encoding: gzip’ HTTP Request Header

<그림2> ‘Content-Encoding: gzip’ HTTP Response

<<HTTP 상태코드>>

상태코드	메시지	의미
트랜잭션이 성공한 경우
100	Continue	클라이언트로부터 일부 요청을 받은 후 나머지 요청 정보를 계속 보내라는 의미.
101	Switching Protocols	서버는 클라이언트의 요청대로 Upgrade 헤더를 따라 다른 프로토콜로 바꿀 것임.
200	OK	에러 없이 전송 성공.
201	Created	서버에서 문서를 만들었음.
202	Accepted	요청이 수행되었지만 처리는 끝나지 않았음.
203	Non-Authoritative Information	서버가 클라이언트의 요구 중 일부만 전송.
204	No Content	클라이언트의 요구를 처리했으나 전송할 데이터가 없음.
205	Reset Content	새문서가 없지만 브라우저를 리셋해야 한다.
206	Partial Content	클라이언트가 Range 헤더와 함께 요청의 일부분을 보냈고 서버는 이를 수행했음.
트랜잭션의 Redirection
300	Multiple Choices	요구된 request가 여러 위치에 존재하는 자원을 필요로 하므로 response는 위에 대한 정보를 보낸다. 클라이언트는 가장 적당한 위치를 선택하여야 함
301	Moved Permanently	요구한 데이터를 변경된 임시 URL에서 찾았음.
302	Found	요구한 데이터를 변경된 임시 URL에 있음을 명시.
303	See Other	요구한 데이터를 변경하지 않았기 때문에 문제가 있음.
304	Not Modified	클라이언트의 캐시에 데이터가 저장되었고 선택적인 요청에 의해 수행됨
305	Use Proxy	요청된 데이터는 Location 헤더에 나열된 프록시를 통해 추출되어야 함.
오류메시지
400	Bad Request	문법상 오류 있어 요청 실패.
401	Unauthorized	권한 실패.
402	Payment Required	예약됨.
403	Forbidden	사용 권한에 관계없이 내용을 볼 수 없음. 종종 파일 이름이 잘못되었거나 서버의 디렉터리 퍼미션이 잘못 되었을 때 나온다.
404	Not found	문서를 찾을 수 없음.
405	Method not Allowed	메소드 허용 안됨.
406	Not Acceptable	요구된 자원을 발견하였으나 자원을 타입이 request header의 accept: 필드와 일치하지 않아서 전송할 수 없음
407	Proxy Authentication Required	Proxy 인증이 필요함.
408	Request timeout	요청시간이 지남
409	Conflict	다른 버전의 파일을 업로드 할 경우.
410	Gone,	영구적으로 사용할 수 없음.
411	Length Required	클라이언트가 Content-Length를 보내지 않으면 서버가 처리할 수 없음.
412	Precondition Failed	요청헤더에 설정 되어 있는 어떤 조건이 맞지 않음.
413	Request Entity Too Large	요청된 문서가 현재 서버가 다룰 수 있는 크기보다 큼.
414	Request URI Too Long	url이 너무 김.
415	Unsupported Media Type	알려지지 않은 형태의 요청.
416	Requested Range Not Satisfiable	클라이언트가 요청에 적당하지 않은 Range 헤더를 포함시켰음.
417	Expectation Failed	Expect요청 헤더의 값이 맞지 않음.
500	Internal Server Error	서버 내부 오류
501	Not Implemented	요청한 것을 서버가 지원하지 않음.
502	Bad Gateway	게이트웨이 상태 나쁨/서버 과부하.
503	Service Unavailable	서버의 과부하, 유지/보수 등으로 요청을 처리할 수 없다.
504	Gateway timeout	초기 서버가 원격서버의 응답을 받을수 없음.
505	HTTP version Not Supported	서버가 요청라인에 지정됨 HTTP버전을 지원하지 않음.

<<HTTP 용어 설명>>
connection(연결)
통신을 목적으로 두 프로그램 간에 설정된 전송 계층의 가상적 회로

message(메시지)
HTTP 통신의 기본 전송 단위. 4 장에 규정된 의미론을 따르는 구조적인 데이터 표현 형태이며, 일련의 8 비트(octets)로 구성되어 있고 연결을 통하여 전송된다.

request(요구)
HTTP 요구 메시지.

response(응답)
HTTP 응답 메시지.

resource(자원)
3.2절에 규정되어 있는 URI에 의하여 식별되는 네트워크 데이터 객체 또는 서비스. 자원은 다양한
표현 형태(예를 들어 언어, 데이터 형식, 크기 및 해상도)를 지닐 수 있으며 다양한 방법으로
변형될 수 있다.

entity(엔터티)
요구나 응답 메시지의 페이로드(payload)로서 전송되는 정보. 엔터티는 7 장에서 설명된 대로
Entity-Header필드 형태의 메타 정보 및 Entity-Body 형태의 내용으로 구성되어 있다.

representation(표현)
12 장에서 기술한 내용 협상의 통제를 따르는 응답에 포함된 엔터티. 특정한 응답 상태와 연관된
다수의 표현 방법이 있을 수 있다.

content negotiation(내용 협상)
12 장에서 기술한 대로 요구를 처리할 때 적절한 표현 방법을 선택하는 메커니즘. 어떠한 응답
에서는 엔터티의 표현은 협상할 수 있다.(에러 응답 포함)

variant(변형자)
자원은 특정한 경우에 자원과 관련된 하나 이상의 표현 방식을 가질 수 있다. 이러한 각각의
표현 방식을 "변형자"라고 부른다. "변형자"라는 용어를 사용한다고 해서 자원이 반드시 내용
협상의 대상인 것은 아니다.

client(클라이언트)
요구 메시지를 전송할 목적으로 연결을 설정하는 프로그램.

user agent(사용자 에이전트)
요구 메시지를 시작하는 클라이언트. 이것은 종종 브라우저, 편집기, 스파이더(웹을 탐색하는
로봇) 또는 다른 사용자 툴(tool)일 수 있다.

server(서버)
요구 메시지를 처리하기 위해 접속을 수신하는 애플리케이션으로서 응답 메시지를 전송한다.
어떤 프로그램이든 동시에 클라이언트와 서버가 될 수 있다. 이 규격에서 이 용어를 사용하는
것은 프로그램의 일반적인 능력을 참조하기보다는 특정한 연결을 위해 프로그램이 수행하는
역할만을 참조하는 것이다.
마찬가지로 어떠한 서버도 원서버, 프락시, 게이트웨이, 터널 등 각 요구의 성격에 따라 동작을
전환하는 역할을 할 수 있다.

origin server(원서버)
해당 자원이 보관되어 있거나 자원을 생성할 수 있는 서버.

proxy(프락시)
다른 클라이언트를 대신하여 요구를 작성할 목적으로 서버와 클라이언트의 역할을 모두 수행하는
중간 프로그램. 요구는 내부적으로 처리되어 가능하면 해석되어 다른 서버로 전달된다. 프락시는
이 규격의 클라이언트와 서버의 필요 조건을 모두 구현해야만 한다.

gateway(게이트웨이)
다른 서버를 위해 중간 역할을 하는 서버. 프락시와는 달리 게이트웨이는 요구 메시지를, 요청
받은 자원을 서비스하는 최종적인 원서버처럼 수신한다. 요구한 클라이언트는 자신이 게이트
웨이와 통신하고 있다는 것을 알지 못할 수 있다.

tunnel(터널)
두 연결 사이를 무조건 중계하는 역할을 하는 중간 프로그램. 활성화되면 비록 HTTP 요구에
의하여 시작되지만 터널은 HTTP 통신의 참여자로 간주되지 않는다. 터널은 중계하고 있는 양
쪽의 연결이 종결되면 사라진다.

cache(캐시)
프로그램이 응답 메시지를 저장하는 로컬 저장소. 메시지 보관, 조회 및 삭제를 제어하는 하부
시스템 이기도하다. 캐시는 응답 시간, 향후 네트워크 대역폭 소모 및 동일한 요구를 감소시킬
목적으로 캐시할 수 있는 응답을 저장한다. 어떤 클라이언트나 서버도 캐시를 포함할 수 있다.
단지 터널 역할을 하는 서버는 캐시를 사용할 수 없다.

cachable(캐시할 수 있는)
응답 메시지의 사본을 저장하여 계속적인 요구 응답에 사용할 수 있으면 응답을 캐시할 수
있다고 한다.
HTTP 응답의 캐시 가능 여부를 결정하는 원칙은 13 장에 정의되어 있다.
자원을 캐시할 수 있다 하더라도 캐시가 특정 요구에 대하여 캐시 된 사본을 사용할 수 있는지
여부에 대한 추가적인 제한 사항이 있을 수 있다.

first-hand(직접)
응답이 직접적으로 오며 원서버로부터 하나 또는 그 이상의 프락시를 거쳐옴으로써 발생하는
불필요한 지연이 없을 경우 응답이 직접 온다고 할 수 있다. 또한 검증이 원서버에서 직접
이루어진다면 응답이 직접 온다고 할 수 있다.

explicit expiration time(명백한 유효 시간)
원서버가 추가적인 검증 없이는 캐시에 의해 엔터티를 더 이상 되돌려 주지 않기로 한 시간.
즉, 원서버가 캐시된 데이터의 유효성을 보장할 수 있는 시간.

heuristic expiration time(자동으로 설정되는 유효 시간)
분명한 유효 시간이 설정되어 있지 않을 때 캐시가 할당하는 유효 시간

age(경과 시간)
응답 메시지의 경과 시간은 원서버로부터 전송된 후, 또는 성공적으로 검증된 후의 시간.

freshness lifetime(신선한 기간)
응답의 생성 시점과 유효시간 만기 시점 사이의 시간 길이

fresh(신선한)
응답의 경과 시간이 신선한 기간을 넘어서지 않았을 때 응답이 신선하다고 할 수 있다.

stale(오래된)
응답의 경과 시간이 신선한 기간을 넘어섰다면 응답이 오래되었다고 할 수 있다.

semantically transparent(의미상으로 분명한)
성능을 향상시키고자 하는 목적을 제외하고 캐시의 사용이 요구하는 클라이언트나 원서버에
영향을 미치지 않을 때 특정한 요구에 대하여 캐시가 "의미상으로 분명하게" 작동한다고 할
수 있다. 캐시가 의미상으로 분명할 때 클라이언트는 원서버가 직접 처리했을 때와 완전히
동일할 응답을 수신하게 된다.( hop-by-hop 헤더는 제외).

validator(검증자)
캐시 엔트리가 엔터티의 복사본과 동일한지 알아내는 데 사용하는 규약 요소(예를 들면 엔터티 태그나 Last-Modified 시간)

참고문헌: RFC2616 (HTTP 전송규약 1.1 표준안)

<<HTTP 실제 헤더>>
아래 헤더 정보는 텍스트만 있는 HTML 문서에 대한 요청/응답 헤더이며,
HTTP Version 1.1을 기준이다.

GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, application/x-silverlight, application/x-silverlight-2-b2, */*
Accept-Language: ko
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Host: www.dreamintek.com
Connection: Keep-Alive

- 요청 헤더 -
GET
지정된 리소스(URI)를 요청

POST
서버가 클라이언트의 폼 입력 필드 데이터의 수락을 요청.
클라이언트는 서버로 HTTP Body 에 Data 를 전송한다

HEAD
문서의 헤더 정보만 요청.
응답데이터(body) 를 받지 않는다

PUT
클라이언트가 전송한 데이터를 지정한 uri 로 대체 한다
ftp 의 put 와 동일.
역시 클라이언트는 서버로 HTTP Body 에 Data 를 전송한다

DELETE
클라이언트가 지정한 URI 를 서버에서 삭제

TRACE
클라이언트가 요청한 자원에 도달하기 까지의 경로를 기록하는
루프백(loop back) 검사용.
클라이언트가 요청 자원에 도달하기 까지 거쳐가는
프록시나 게이트웨이의 중간 경로부터 최종 수진 서버까지의 경로를 알아낼 때 사용.

① GET /index.htm HTTP /1.1
요청 method 와 요청 파일정보,http 버전.
HTTP 프로토콜은 클라이언트가 서버에게 요청하는 방식에 대한 몇 가지 동작을 정의하고 있습니다.
즉, 요청 method 란 클라이언트가 서버로의 요청하는 방법을 명시합니다
② Accept : 클라이언트가 허용할 수 있는 파일 형식(MIME TYPE)
*/* 은 특정 유형이 아닌 모든 파일형식을 다 지원한다는 뜻입니다
③ User-Agent : 클라이언트 소프트웨어(브라우저,os등) 의 이름과 버전 등.
위의 정보에서는 MS IE 6.0, 윈도우 XP, .NET Framework 1.1 버전이 클라이언트에 설치되어 있음을 나타냅니다
④ Host : 요청을 한 서버의 Host로써, ‘www.dreamintek.com’에 대한 페이지 요청 입니다        
⑤ If-Modified-Since : 페이지가 수정되었으면 최신 버전 페이지 요청을 위한 필드. 만일 요청한 파일이 이 필드에 지정된 시간 이후로 변경되지 않았다면, 서버로부터 데이터를 전송 받지 않습니다. 단, 이 경우 서버로부터 net modified (304) 상태코드를 전송 받습니다
⑥ Refer : 특정 페이지에서 링크를 클릭하여 요청을 하였을 경우에 나타나는 필드로써 링크를 제공한 페이지를 나타냅니다
⑦ Cookie : 웹 서버가 클라이언트에 쿠키를 저장해 놓았다면 해당 쿠키의 정보를 이름-값 쌍으로 웹 서버에게 전송합니다
⑧ Accept-Language : 클라이언트가 인식할 수 있는 언어.
우선 순위 지정이 가능합니다
⑨ Accept-Encoding : 클라이언트가 인식할 수 있는 인코딩(압축) 방법
위의 내용에서는 서버에서 gzip,deflate 로 압축한 리소스를 클라이언트가 해석 할 수 있다는 말이 됩니다. 만일 서버에서 압축을 했으면 응답헤더에 Content-Encoding 헤더에 해당 압축 방법이 명시 됩니다

- 응답 헤더 -
HTTP/1.1 200 OK
Date: Wed, 15 Oct 2008 06:18:03 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
Keep-Alive: timeout=15
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
Content-Language: ko

① HTTP /1.1 200 OK : HTTP 버전과 응답 코드 (200 성공)
② Server : 웹 서버 정보를 나타냅니다
③ Date :  현재 날짜
④ Content-Type : 요청한 파일의 MIME 타입을 나타냅니다
Text/html 은 text 중 html 파일임을 나타냅니다
⑤ Last-Modified : 요청한 파일의 최종 수정일을 나타냅니다
⑥ Content-Length : 헤더 이후 이어지는 데이터의 길이입니다(바이트 단위)
이어지는 데이터란 요청한 파일의 데이터라 보시면 됩니다
⑦ ETag : 캐시 업데이트 정보를 위한 임의의 식별 숫자

참조:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

[출처] HTTP Header|작성자 루나