HTTP Header (헤더)
HTTP Header (헤더)
| 카테고리 | 요청 | 응답 | 헤더 |
|---|---|---|---|
| 일반 헤더 | ○ | ○ | Cache-Control, Connection, Date, Pragma, Trailer,Transfer-Encoding, Upgrade, Via, Warning |
| 요청 헤더 | ○ | × | Accept, Accept-Charset, Accept-Encoding, Accept-Language, Authorization, Expect, From, Host, If-Match, If-Modified-Since, If-None-Match, If-Range, If-Unmodified-Since, Max Forwards, Proxy-Authorization, Range, Referer, TE, User-Agent |
| 응답 헤더 | × | ○ | Accept-Ranges, Age, ETag, Location, Proxy-Authenticate, Retry-After, Server, Vary, WWW-Authenticate |
| 요소 헤더 | ○ | ○ | Allow, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, Expires, Last-Modified, extension-header |
Accept (요청)
브라우저가 수신할 수 있는 데이터 형식(MIME 타입)을 서버에 전달한다. 별표(*)는 “모두"를 의미한다. 다음은 브라우저가 GIF, JPEG 및 기타 모든 형식의 데이터를 수신할 수 있음을 보여준다. (→ Content-Type)
Accept: image/gif, image/jpeg, */*
Accept-Charset (요청)
브라우저가 수신 가능한 문자 세트를 서버에 전달한다. 다음은 브라우저가 iso-8859-5, euc-kr만 수신할 수 있다를 뜻한다. (→ Content-Type)
Accept-Charset: iso-8859-5, euc-kr
Accept-Encoding (요청)
브라우저가 수신 가능한 인코딩 방식을 서버에 전달한다. 예를 들어, 브라우저가 gzip 형식을 서포트하고 있는 것을 서버에 전하면, 서버는 메세지 본문을 자동적으로 gzip 압축해 브라우저에 보내서 브라우저에 이를 자동적으로 해제하여 화면에 표시한다. 이러한 기능으로 의해, 통신 부하를 저감하는 것이 가능하다. (→ Content-Encoding )
Accept-Encoding: gzip, deflate
Accept-Language (요청)
브라우저가 수신 가능한 언어를 서버에 전달한다. 아래는 브라우저가 한국어만 수신할 수 있음을 의미한다. (→ Content-Language )
Accept-Language: ko
Accept-Ranges (응답)
Range 요청에서 사용 가능한 단위를 클라이언트에 전달한다. 현재 정의되어 있는 것은 bytes 뿐이다. (→ Range, Content-Range )
Accept-Ranges: bytes
Age (응답)
엔티티가 생성된 이후의 예상 경과 시간(초)을 나타낸다. 아래의 예에서는, 이 엔티티가 아마, 프록시 서버로 30초간 유지된 것, 즉, 30초 정도 오래된 데이터인 것을 나타낸다.
Age: 30
Allow (요청/응답)
요청 URL에 표시된 리소스에 사용할 수 있는 메서드 목록을 제공한다. 다음 예제에서는 이 리소스에 대해 GET, HEAD, PUT 메서드를 사용할 수 있음을 보여 준다.
Allow: GET, HEAD, PUT
Authorization (요청)
인증이 필요한 자원에 대한 인증 정보를 전달한다. 예를 들어, BASIC 인증의 경우는, Basic 의 문자와, 유저명과 패스워드를 콜론(:)으로 연결한 것을 BASE64 형식에 encode 한 것을 전송한다. (→ WWW-Authenticate )
Authorization: Basic dGFuYWthOmhpbWl0c3U=
Cache-Control (요청/응답)
캐시에 관한 지시를 나타낸다. 다음 예제는 프록시 서버와 클라이언트가 이 리소스를 캐시해서는 안 됨을 보여준다. HTTP/1.0에서는 Pragma: no-cache가 사용된다. (→ Pragma )
Cache-Control: no-cache
Connection (요청/응답)
HTTP/1.1에서 지원되는 지속 연결 기능을 브라우저가 지원하는 경우, 그 취지를 상대에게 알린다. 지속적인 연결을 사용하면 단일 연결에서 여러 요청/응답을 발행할 수 있다.
Connection: Keep-Alive
지속 연결을 완료하면 서버는 close를 반환한다.
Connection: close
그 외에도 서버 프록시 간, 프록시 클라이언트 간과 같은 직접 연결에만 유효한 헤더 목록을 표시하는데 사용된다. 프록시 서버는 이 헤더로 지정된 헤더 정보를 삭제해, 전송하지 않으면 안된다.
Connection: Upgrade
Content-Encoding (요청/응답)
콘텐츠 인코딩 방법을 나타낸다. 다음은 콘텐츠가 gzip 형식으로 압축되었음을 나타낸다. (→ Accept-Encoding )
Content-Encoding: gzip
Content-Language (요청/응답)
컨텐츠의 언어를 en(영어), ko(한국어) 등으로 나타낸다.
Content-Language: ko
Content-Length (요청/응답)
컨텐츠(=메시지 본체)의 길이를 바이트 단위로 나타낸다. 헤더와 메시지 본문 사이의 줄 바꿈 바이트 수는 제외한다.
Content-Length: 4891
Content-Location (요청/응답)
컨텐츠가 다른 URL에서도 액세스 가능할 때, 그 엔티티의 URL를 절대 URL 또는 상대 URL 로 나타낸다. (→ Location )
Location: http://xxx.yyy.zzz/index.htm
Content-MD5 (요청/응답)
콘텐츠가 통신 도중에 변경되지 않았는지 확인하기 위해 콘텐츠에 대한 체크 데이터(128비트 MD5 다이제스트를 BASE64로 인코딩)를 나타낸다.
Content-MD5: GitH4qFa4GasgWxJs8ha5Q==
Content-Range (요청/응답)
상대에게 보낼 콘텐츠의 범위를 나타낸다. 아래 예에서는 전체 콘텐츠가 12345바이트이고 그 안의 0바이트부터 999바이트까지의 부분을 전송하고 있음을 보여준다. (→ Range , Accept-Ranges )
Content-Range: bytes 0-999/12345
Content-Type (요청/응답)
Content-Type 를 MIME 타입으로 나타낸다. MIME 타입은 리소스(파일) 유형을 말한다.
다음은 콘텐츠의 내용이 텍스트(HTML) 형식임을 나타낸다.
Content-Type: text/html
또한 문자 코드 (euc-kr, ISO-2022-KR, UTF-8 등)를 나타낼 수도 있다.
Content-Type: text/html; charset=euc-kr
응답 헤더을 실제 확인해 보도록 하자.
Content-Type 응답 헤더
$ curl http://google.com/ --head
...
Content-Type: text/html; charset=UTF-8
문자 코드가 UTF-8인 HTML을 응답했다는 것을 의믜한다.
Date (요청/응답)
응답을 반환하는 시간을 나타낸다. 요일(Sun,)은 선택 사항이다. 날짜는 1 또는 01일 수 있다. 연도는 2자리 또는 4자리일 수 있지만 4자리가 권장된다. 초(:23)는 선택 사항이다. 시간대는 GMT(그리니치 표준시)를 이용하는 경우가 많다.
Date: Sun, 04 Jan 2004 16:06:23 GMT
ETag (응답)
엔티티와 그 버전을 고유하게 식별하는 식별자를 나타낸다. 식별자는 파일 식별자, 크기, 갱신 시간 등의 정보로부터 계산된다. (→ If-Match , If-None-Match , If-Range )
ETag: "1dba6-131b-3fd31e4a"
Expect (요청)
다양한 목적으로 사용된다.
Expect: 100-continue
Expires (요청/응답)
엔티티의 만료 날짜를 표시한다. 만료일이 지난 엔티티는 캐시에서 삭제된다.
Expires: Thu, 01 Dec 2021 16:00:00 GMT
From (요청)
이 요청을 한 사람의 이메일 주소를 지정한다. 검색 엔진이 로봇으로 탐색하는 경우에, 검색에 관한 문의처의 메일 주소를 통지할 때 등에 이용된다.
From: aaa@xxx.yyy.zzz
Host (요청)
Host 요청 헤더는 요청이 전송되는 서버의 호스트 이름과 포트 번호를 지정한다.
HTTP/1.1에서 유일한 필수 헤더이다. 브라우저에서 서버로 서버 이름을 보낸다. 서버가 이름 베이스의 가상 호스트를 지원하고 있다면 그 이름으로 어느 서버로서 동작할지 결정된다.
예를 들어, http://aaa.devkuma.com 와 http://bbb.devkuma.com 는 실은 같은 서버(IP 주소: 183.111.100.230)이지만, Host 헤더로 호스트명을 지정하는 것으로, 가상 두 개의 서버로 작동 할 수 있다.
Host 요청 확인
% curl www.devkuma.com -v
> Host: www.devkuma.com
포트 번호를 지정하지 않으면 요청한 서비스의 기본 포트(예: HTTPS URL이면 443, HTTP URL인 경우 80)로 간주된다.
If-Match (요청)
지정된 ETag와 일치하는 경우에만 메소드를 실행하도록 서버에 요청한다. (→ ETag , If-None-Match)
If-Match: "1dba6-131b-3fd31e4a"
If-Modified-Since (요청)
클라이언트측이 벌써 캐쉬를 가지고 있는 경우, 캐쉬의 일자를 서버에 통지해, 「이 일자보다 새로운 것이 있으면 전송해 주세요」라고 요구한다. 업데이트되지 않은 경우 서버는 304 (not modified) 상태를 반환하고 브라우저는 캐시 된 데이터를 표시한다. (→ If-Unmodified-Since)
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match (요청)
지정한 ETag와 일치하지 않는 경우에만 메소드를 실행할 것을 서버에 의뢰한다. (→ ETag , If-Match)
If-None-Match: "1dba6-131b-3fd31e4a"
If-Range (요청)
클라이언트가 엔티티의 일부를 이미 보유하고있는 경우, “이 ETag에 지정된 엔티티의 일부가 최신이면 나머지 모든 것을, 그렇지 않으면 전체를 보낸다. ‘의 의미로 요구한다. Range 헤더와 함께 사용한다. (→ ETag , Range)
Range: bytes=0-1023
If-Range: "1dba6-131b-3fd31e4a"
If-Unmodified-Since (요청)
엔티티가, 지정된 일자보다 나중에 갱신되어 있지 않은 경우, 요구를 처리한다. 업데이트된 경우 서버는 412(Precondition Failed) 상태를 반환한다. (→ If-Modified-Since)
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Last-Modified (요청/응답)
엔티티가 마지막으로 업데이트된 시간을 나타낸다. (→ If-Modified-Since )
Last-Modified: Sun, 07 Dec 2003 12:34:18 GMT
Location (응답)
Location 응답 헤더는 리디렉션 대상 URL을 나타낸다.
엔티티 위치가 이동 했을 때, 브라우저가 요구한 URL 과는 다른 URL로 이동시키고 싶은 경우에 사용한다.
URL은 http:// 또는 https://로 시작하는 절대 URL을 지정한다. (→ Content-Location )
Location: [URL]
Location 응답 헤더
% curl http://google.com/ --head
...
Location: http://www.google.com/
위에 예제는 ‘http://google.com/' 대신에 ‘http://www.google.com/'을 접근해 달라는 것을 뜻한다.
Max-Forwards (요청)
OPTIONS 및 TRACE 메소드으로 프록시 서버의 통신 상대에게 도달할 때까지 경유하는 전송·중계 설비의 최대 수를 지정한다. 프록시 서버는 이 값을 하나씩 빼가면서, 다음의 프록시 서버에 전송 한다. 이 값이 0이 되면, 프록시 서버는 마지막 수신자로서 응답을 돌려준다.
Max-Forwards: 16
Pragma (요청/응답)
다양한 목적으로 사용된다. 예를 들어, 다음은 캐시를 사용하지 않겠다고 프록시 서버나 클라이언트에 전달한다. (→ Cache-Control )
Pragma: no-cache
Proxy-Authenticate (응답)
프록시 서버와 클라이언트 간에 인증이 필요함을 나타낸다. (→ Proxy-Authorization , WWW-Authenticate )
Proxy-Authenticate: Basic realm="XXXXXX"
Proxy-Authorization (요청)
프록시 서버와 클라이언트 사이의 자격 증명을 전달한다. (→ Proxy-Authenticate , Authorization)
Proxy-Authorization: Basic dGFuYWthOmhpbWl0c3U=
Range (요청)
클라이언트에서 서버로 엔티티의 일부만 요청한다. 아래 예제에서는 페이지의 처음 1000바이트(0바이트에서 999바이트째)만 요청한다. (→ Accept-Ranges , Content-Range , If-Range)
Range: bytes=0-999
Referer (요청)
이 요청의 원본이 된 페이지의 URL(일반적으로 링크 소스 URL)을 전달한다.
Referer: http://xxx.yyy.zzz/index.html
Retry-After (응답)
몇 초 후에 다시 요청해 준다는 의미에서 503(Service Unavailable)이나 3xx(Redirection) 상태와 함께 반환된다. 아래는 120초 후에 다시 요청해 주는 의미를 가진다. Date: 형식의 절대 시간을 반환할 수도 있다.
Retry-After: 120
Server (응답)
서버로부터 브라우저에 서버 정보를 돌려즌다. 형식은 특별히 규정되지 않는다.
Server: Apache/1.3.22 (Unix) (Red-Hat/Linux)
TE (요청)
브라우저가 처리 가능한 확장 전송 코딩 방식 (chunked 등)이나 청크 전송시의 trailer 필드를 해석 가능한가 어떤가를 서버에 전달한다.
TE: trailers
Trailer (요청/응답)
헤더 정보를 컨텐츠의 선두가 아니고, 청크 형식으로 분할 송신된 컨텐츠의 뒤에 부가하는 경우, 거기에 부가된 헤더의 일람을 나타낸다. 이는 CGI가 데이터를 전송한 후 Content-Length 헤더를 추가하려는 경우에 유용한다.
Trailer: Content-Length
Transfer-Encoding (요청/응답)
전송에 사용되는 인코딩 형식을 나타낸다.
Transfer-Encoding: chunked
Upgrade (요청/응답)
다른 프로토콜을 사용할 것을 권장한다는 것을 상대에게 알린다. 클라이언트 프록시 간과 같은 직접 연결에만 유효한다.
Upgrade: HTTP/2.0, SHTTP/1.3
User-Agent (요청)
User-Agent는 클라이언트의 응용 프로그램 이름, OS 이름 등을 나타낸다.
브라우저(=사용자 에이전트)의 정보를 서버에 전달한다. 형식은 특별히 규정되지 않는다. 브라우저 유형, 버전, 플랫폼 등의 정보가 포함된다.
% curl www.devkuma.com -v
> User-Agent: curl/7.77.0
Mac OS에 Chrome으로 요청을 하면 아래와 같이 표시된다. (→ 서버 )
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36
Vary (응답)
Accept , Accept-Charset , Accept-Language 등, 서버 주도형 네고시에이션으로 사용된 헤더 정보를 나타낸다. 이것은 캐시의 유효성을 결정하는 데 유용한다. 예를 들어, 다음 예제에는 Accept-Language가 포함다. 이는 브라우저가 Accept-Language : ko를 전송했기 때문에 서버가 일본어 콘텐츠를 반환했을 수 있으며 Accept-Language : en에서 요청하면 다른 콘텐츠가 반환 될 수 있다. 있음을 나타낸다.
Vary: Accept-Charset, Accept-Language
Via (요청/응답)
메시지의 전달 경로를 나타낸다. 다음 예는 메시지가 aaa → bbb → ccc라는 프록시를 라우트하여 전달되었음을 보여준다. 1.1은 프로토콜 버전이다.
Via: 1.1 aaa, 1.1 bbb, 1.1 ccc
Warning (요청/응답)
상태 행에 추가되는 경고 코드와 메시지를 전달한다.
Warning: 110 xxxsv "Response is stale"
WWW-Authenticate (응답)
인증이 필요함을 나타낸다. 다음 예제는 이 리소스가 BASIC 인증이라는 HTTP에서 가장 기본적인 방식으로 보호됨을 보여준다. XXXXXX 부분에는 이 인증에 대한 설명문이 들어 있다. (→ Authorization )
WWW-Authenticate: Basic realm="XXXXXX"
extension-header (요청/응답)
이외에도, 서버의 구현에 의해 다양한 헤더가 구현되고 있다.
가상 호스트
HTTP/1.1에서는 가상 호스트가 지원된다. HTTP/1.1 의 클라이언트는 Host 헤더로 호스트명을 송신하지 않으면 안된다. 서버는 가상 호스트에 해당하는 컨텐츠를 응답한다. 이를 통해 한 서버에서 여러 웹 사이트를 지원할 수 있다.
요청
GET / HTTP/1.1
Host: www.devkuma.com
지속적인 연결 (Keep-Alive)
초기의 HTTP는 HTTP 요청을 보낼 때 마다 새로운 소켓 연결이 맺어졌었다. 이 방법은 효율적이지 못하다.
지속성 있는 연결(Persistent Connections)은 이렇게 같은 서버에 여러 개의 소켓 연결을 맺는 비효율 문제를 해결하기 위해 HTTP/1.0의 Keep-Alive가 나와 표준이 되었다.
즉, 하나의 연결 안에 여러 개의 요청을 보내는 것이다. 클라이언트는 아래와 같이 1회의 TCP 접속으로 복수의 컨텐츠를 요구하는 것으로, 통신 퍼포먼스를 향상시킬 수 있다. 지속 접속을 계속하는 경우에는 통상 Connection 헤더로 Keep-Alive 를, 마지막의 요구에는 close 를 지정한다.
브라우저와 서버는 헤더의 Connetion 속성에 Keep-alive 값을 지정할 수 있다. HTTP/1.1에서는 필요하지 않지만 대부분의 브라우저와 서버는 이 값을 계속 포함하고 있다.
요청
GET /aaa.html HTTP/1.1
Host: www.devkuma.com.com
Connection: Keep-Alive
GET /bbb.html HTTP/1.1
Host: www.devkuma.com.com
Connection: close
이에 대해 서버는 Content-Length나 청크(후술)등으로 복수의 컨텐츠의 경계가 명시된 컨텐츠를 돌려준다. timeout 에는 다음의 요구가 오지 않는 경우에 타임 아웃을 발생시키는 시간(초), max 에는 이 지속 접속으로 요구 가능한 요구의 남은 횟수가 지정된다.
응답
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
(aaa.html 콘텐츠)
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
Keep-Alive: timeout=5, max=99
Connection: close
(bbb.html 콘텐츠)
청크 (chunked)
CGI 결과 반환에서 콘텐츠를 생성할 때 콘텐츠의 길이를 모르는 경우와 같이 서버는 청크 형식의 데이터를 반환할 수 있다. 청크 형식의 데이터에서 연속 데이터의 바이트 수는 16진수로 표시된다. 0은 데이터의 끝을 의미한다.
응답
HTTP/1.1 200 OK
Content-Type: text/html
Transfer-Encoding: chunked
1234년
(16진수로 1234바이트 데이터)
9ab
(16진수로 9ab 바이트의 데이터)
0
(콘텐츠 종료)
BASIC 인증
HTTP 베이직 인증을 사용하면 서버는 클라이언트의 요청에 대해 WWW-Authenticate 헤더를 반환한다.
응답
HTTP/1.1 200 OK
WWW-Authenticate: Basic realm="HIMITSU No PAGE"
클라이언트는 WWW-Authenticate 헤더를 받으면 로그인명과 패스워드의 입력을 촉구하는 다이얼로그를 표시해, 유저가 입력한 로그인명과 패스워드를 encode 하여 다시 컨텐츠 요청을 한다.
요청
HTTP/1.1 200 OK
Host: www.devkuma.com
Authorization: Basic abcdEFGhiJklM==