[메시지의 흐름]
HTTP 메시지는 HTTP 애플리케이션 간에 주고받은 데이터의 블록들이다.
데이터 블록들은 메시지의 내용과 의미를 설명하는 텍스트 메타 정보로 시작하고, 그 다음에 선택적으로 데이터가 올 수 있다.
메시지는 클라이언트, 서버, 프락시 사이를 흐르며, '인바운드', '아웃바운드', '업스트림', '다운스트림'은 메시지의 방향을 의미하는 용어다.
1) 메시지는 원 서버 방향을 인바운드로 하여 송신된다.
HTTP는 인바운드와 아웃바운드라는 용어를 트랜잭션 방향을 표현하기 위해 사용한다.
- 인바운드: 메시지가 원 서버로 향하는 것
- 아웃바운드: 메시지가 사용자 에이전트로 돌아오는 것
2) 다운스트림으로 흐르는 메시지
요청 메시지냐 응답 메시지냐에 관계없이 모든 메시지는 다운스트림으로 흐른다.
[메시지의 각 부분]
HTTP 메시지는 단순한, 데이터의 구조화된 블록이다.
각 메시지는 클라이언트로부터의 요청이나 서버로부터의 응답 중 하나를 포함한다.
메시지는 시작줄, 헤더 블록, 본문(선택)으로 이루어진다.
시작줄과 헤더는 줄 단위로 분리된 아스키 문자열이다. 각 줄은 캐리지 리턴과 개행 문자로 구성된 두 글자의 줄바꿈 문자열로 끝난다.
본문은 선택적인 데이터 덩어리이다. 본문은 텍스트나 이진 데이터를 포함할 수도 있고, 비어있을 수도 있다.
1) 메시지 문법
요청 메시지의 형식
<메서드> <요청 URL> <버전>
<헤더>
<엔터티 본문>
응답 메시지의 형식
<버전> <상태 코드> <사유 구절>
<헤더>
<엔터티 본문>
- 메서드: 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작
- 요청 URL: 요청 대상이 되는 리소스를 지칭하는 완전한 URL 혹은 URL의 경로 구성요소다
- 버전: 메시지에서 사용 중인 HTTP의 버전이다.
형식 - HTTP/<메이저>, <마이너>
- 상태 코드: 요청 중에 무엇이 일어났는지 설명하는 3자리 숫자
- 사유 구절: 숫자로 된 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구
상태 코드 이후부터 줄바꿈 문자열까지가 사유 구절이다. 이는 오로지 사람에게 읽히기 위한 목적으로 존재한다.
- 헤더: 이름, 콜론(:), 선택적인 공백, 값, CRLF가 순서대로 나타나는 0개 이상의 헤더들
- 엔터티 본문: 임의의 데이터 블록을 포함한다
2) 시작줄
모든 HTTP 메시지는 시작 줄로 시작한다.
메서드, 상태 코드, 사유 구절, 버전 번호 등이 포함된다.
3) 헤더
HTTP 헤더 필드는 요청과 응답 메시지에 추가 정보를 더한다. 기본적으로 이름/값 쌍의 목록이다.
4) 엔티티 본문
엔티티 본문은 이미지, 비디오, HTML 문서, 소프트웨어 애플리케이션, 신용카드 트랜잭션, 전자우편 등 여러 종류의 디지털 데이터를 실어 나를 수 있다.
[메서드]
1) GET
GET은 주로 서버에게 리소스를 달라고 요청하기 위해 쓰인다.
2) HEAD
HEAD 메서드는 정확히 GET 처럼 동작하지만, 서버는 응답으로 헤더만을 반환하며 엔티티 본문은 반환되지 않는다.
HEAD를 사용하는 이유
- 리소스를 가져오지 않고도 그에 대해 무엇인가를 알아낼 수 있다.
- 응답의 상태코드를 통해 개체의 존재 여부를 확인할 수 있다.
- 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.
3) PUT
PUT 메서드는 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나 이미 URL이 존재한다면 본문을 사용해서 교체한다.
PUT은 콘텐츠 변경을 하도록 해주므로, 웹 서버가 PUT을 수행하기 전에 사용자 인증을 해야한다.
4) POST
POST 메서드는 서버에 입력 데이터를 전송하기 위해 설계되었다.
5) TRACE
클라이언트가 어떤 요청을 할 때, 그 요청은 방화벽, 프락시, 게이트웨이 등의 애플리케이션을 통과할 수 있다. 이들한테는 원래의 HTTP 요청을 수정할 수 있는 기회가 있으며, TRACE 메서드는 클라이언트에게 자신의 요청이 서버한테 도달했을 때 어떻게 보이는지 알려준다.
TRACE 메서드는 주로 진단을 위해 사용된다. 요청이 의도한 요청/응답 연쇄를 거쳐가는지 검사할 수 있으며, 프락시나 다른 애플리ㅔ이션들이 요청에 어떤 영향을 미치는지 확인해보고자 할 때도 좋은 도구다.
6) OPTIONS
OPTIONS 메서드는 웹 서버에게 여러가지 종류의 지원범위에 대해 물어본다.
서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있다.
7) DELETE
DELETE 메서드는 서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청한다.
[상태코드]
HTTP 상태 코드는 크게 5가지로 나뉜다.
상태 코드는 클라이언트에게 트랜잭션을 이해할 수 있는 쉬운 방법을 제공한다.
1) 100-199: 정보성 상태 코드
HTTP/1.1에서 도입된 상태 코드이다.
| 상태 코드 |
사유 구절 |
의미 |
| 100 |
Continue |
요청의 시작 부분 일부가 받아들여졌으며, 클라이언트는 나머지를 계속 이어서 보내야 함을 의미한다. 이것을 보낸 후 서버는 반드시 요청을 받아 응답해야 한다. |
| 101 |
Switching Protocols |
클라이언트가 Upgrade 헤더에 나열한 것 중 하나로, 서버가 프로토콜을 바꾸었음을 의미한다. |
100 Continue
- 의미: 클라이언트가 서버에 HTTP 요청의 일부를 보냈을 때, 서버가 이를 확인하고 나머지 요청을 계속해서 보내도 된다는 신호를 의미한다.
- 사용 시나리오: 주로 클라이언트가 큰 데이터를 전송할 때 사용된다. 예를 들어, 클라이언트가 Expect: 100-continue 헤더를 포함하여 서버에 요청을 보내면, 서버는 요청의 헤더 부분만 먼저 확인한 후, 문제가 없다면 100 Continue 응답을 보낸다. 이후 클라이언트는 본문 데이터를 계속해서 전송할 수 있다.
- 흐름 예시:
- 클라이언트가 서버에 큰 파일을 업로드하려고 한다. 먼저 헤더를 포함한 요청을 보낸다.
- 서버가 헤더를 확인한 후, 클라이언트에게 100 Continue 응답을 보낸다.
- 클라이언트는 서버로부터 100 Continue를 받으면 파일 본문을 전송한다.
- 서버는 나머지 요청을 처리한 후 최종 응답(예: 200 OK)을 클라이언트에게 보낸다.
2) 200-299: 성공 상태 코드
| 상태 코드 |
사유 구절 |
의미 |
| 200 |
OK |
요청은 정상이며, 엔티티 본문은 요청된 리소스를 포함하고 있다. |
| 201 |
Created |
서버 개체를 생성하라는 요청(PUT, POST, ...)를 위한 것
응답은 생성된 리소스에 대한 최대한 구체적인 참조가 담긴 Location 헤더와 함께, 그 리소스를 참조할 수 있는 여러 URL을 엔티티 본문에 포함해야 한다. |
| 202 |
Accepted |
요청은 받아들여졌으나 서버는 아직 그에 대한 어떤 동작도 수행하지 않았다.
서버가 요청의 처리를 완료할 것인지에 대한 어떤 보장도 없으며, 단지 요청이 받아들이기에 적법해 보인다는 의미이다. |
| 203 |
Non-Authoritative Information |
엔티티 헤더에 들어있는 정보가 원래 서버가 아닌 리소스의 사본에서 왔다.
중개자가 리소스의 사본을 갖고 있었지만 리소스의 메타 정보를 검증하지 못한 경우 이런 일이 발생할 수 있다. |
| 204 |
No Content |
응답 메시지는 헤더와 상태줄을 포함하지만 엔티티 본문은 포함하지 않는다. 주로 웹브라우저를 새 문서로 이동시키지 않고 갱신하고자 할 때, 사용한다. |
| 205 |
Reset Content |
브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우라고 말한다. |
| 206 |
Partial Content |
부분, 범위 요청이 성공했다.
이 응답은 Content-Range와 Date 헤더를 반드시 포함해야 하며, Etag와 Content-Location 중 하나의 헤더도 반드시 포함해야 한다. |
3) 300-399: 리다이렉션 상태 코드
리다이렉션 상태 코드는 클라이언트가 관심있어하는 리소스에 대해 다른 위치를 사용하라고 말해주거나, 그 리소스의 내용 대신 다른 대안 응답을 제공한다.
만약 리소스가 옮겨진 경우, 클라이언트에게 리소스가 옮겨졌으며 어디서 찾을 수 있는지 알려주기 위해 리다이렉션 상태코드와 Location 헤더를 보낼 수 있다. 이는 브라우저가 알아서 새 위치로 이동할 수 있게 해준다.
| 상태 코드 |
사유 구절 |
의미 |
| 300 |
Multiple Choices |
클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청한 경우, 그 리스트 목록과 함께 반환된다.
사용자는 목록에서 원하는 하나를 선택할 수 있다. |
| 301 |
Move Permanently |
요청한 URL이 옮겨졌을 때 사용한다.
응답은 Location 헤더에 현재 리소스가 존재하고 있는 URL을 포함해야 한다. |
| 302 |
Found |
301 상태 코드와 같다.
그러나 클라이언트는 Location 헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용해야 한다. |
| 303 |
See Other |
클라이언트에게 리소스를 다른 URL에서 가져와야 한다고 말해주고자 할 때 사용한다. |
| 304 |
Not Modified |
클라이언트가 GET과 같은 조건부 요청을 보냈고, 그 요청한 리소스가 최근에 수정된 일이 없다면 이 코드는 리소스가 수정되지 않았음을 의미하게 된다. |
| 305 |
Use Proxy |
리소스가 반드시 프락시를 통해서 접근되어야 함을 나타내기 위해 사용한다.
프락시의 위치는 Location 헤더를 통해 주어진다. |
| 306 |
(사용되지 않음) |
|
| 307 |
Temporary Redirect |
301 상태 코드와 비슷하나 클라이언트는 Location 헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용해야 한다. 이후의 요청에서는 원래 URL을 사용해야 한다. |
4) 400-499: 클라이언트 에러 상태 코드
클라이언트는 서버가 다룰 수 없는 무엇인가를 보낼 때가 있다.
| 상태 코드 |
사유 구절 |
의미 |
| 400 |
Bad Request |
클라이언트가 잘못된 요청을 보냈다고 말해준다. |
| 401 |
Unauthorized |
리소스를 얻기 전에 클라이언트에게 스스로를 인증하라고 요구하는 내용의 응답을 적절한 헤더와 함께 반환한다. |
| 402 |
Payment Required |
- |
| 403 |
Forbidden |
요청이 서버에 의해 거부되었음을 알려주기 위해 사용한다.
서버의 요청 거부 이유를 엔티티 본문에 포함시킬 수 있지만, 보통은 서버의 거절 이유를 숨기기 위해 이 상태 코드를 사용한다. |
| 404 |
Not Found |
서버가 요청한 URL을 찾을 수 없음을 알려주기 위해 사용한다. |
| 405 |
Method Not Allowed |
요청한 URL에 대해 지원하지 않는 메서드로 요청받았을 때 사용한다.
요청한 리소스에 대해 어떤 메서드가 사용 가능한지 클라이언트에게 알려주기 위해 요청에 Allow 헤더가 포함되어야 한다. |
| 406 |
Not Acceptable |
클라이언트는 자신이 어떤 종류의 엔티티를 받아들이고자 하는지에 대해 매개변수로 명시할 수 있다. |
| 407 |
Proxy Authentication
Required |
401 상태 코드와 같으나 리소스에 대해 인증을 요구하는 프락시 서버를 위해 사용한다. |
| 408 |
Request Timeout |
클라이언트의 요청을 완수하기에 시간이 너무 많이 걸리는 경우, 서버는 이 상태 코드로 응답하고 연결을 끊을 수 있다. |
| 409 |
Conflict |
요청이 리소스에 대해 일으킬 수 있는 몇몇 충돌을 지칭하기 위해 사용한다.
응답은 충돌에 대해 설명하는 본문을 포함해야 한다. |
| 410 |
Gone |
404와 비슷하나 서버가 한때 그 리소스를 갖고 있엇다는 점이 다르다. |
| 411 |
Length Requried |
서버가 요청 메시지에 Content-Length 헤더가 있을 것을 요구할 때 사용한다. |
| 412 |
Precondition Failed |
클라이언트가 조건부 요청을 했는데, 그 중 하나가 실패했을 때 사용한다. |
| 413 |
Request Entity Too Large |
서버가 처리할 수 있는, 처리하고자 하는 한계를 넘은 크기의 요청을 클라이언트가 보냈을 때 사용한다. |
| 414 |
Request URI Too Long |
서버가 처리할 수 있는, 처리하고자 하는 한계를 넘은 크기의 요청 URL이 포함된 요청을 클라이언트가 보냈을 때 사용한다. |
| 415 |
Unsupported Media Type |
서버가 이해하거나 지원하지 못하는 내용 유형의 엔티티를 클라이언트가 보냈을 때 사용한다. |
| 416 |
Request Range Not Satisfiable |
요청 메시지가 리소스의 특정 범위를 요청했는데, 그 범위가 잘못되었거나 맞지 않을 때 사용한다. |
| 417 |
Expectation Failed |
요청에 포함된 Expect 요청 헤더에 서버가 만족시킬 수 없는 기대가 담겨 있는 경우 사용한다. |
5) 500-599: 서버 에러 상태 코드
클라이언트가 올바른 요청을 보냈음에도 서버 자체에서 에러가 발생하는 경우가 있다. 이것은 클라이언트가 서버의 제한에 걸린 것일 수도 있고, 게이트웨이 리소스와 같은 서버의 보조 구성요소에서 발생한 에러일 수도 있다,
| 상태 코드 |
사유 구절 |
의미 |
| 500 |
Internal Server Error |
서버가 요청을 처리할 수 없게 만드는 에러를 만났을 때 사용한다 |
| 501 |
Not Implemented |
클라이언트가 서버의 능력을 넘은 요청을 했을 때 사용한다.
(예시: 서버가 지원하지 않는 메서드를 사용) |
| 502 |
Bad Gateway |
프락시나 게이트웨이처럼 행동하는 서버가 그 요청 응답 연쇄에 있는 다음 링크로부터 가짜 응답에 맞닥뜨렸을 때 사용한다.
(예시: 자신의 부모 게이트웨이에 접속하는 것이 불가능할 때) |
| 503 |
Service Unavailable |
현재는 서버가 요청을 처리해줄 수 없지만 나중에 가능함을 의미하고자 할 때 사용한다. |
| 504 |
Gateway Timeout |
다른 서버에게 요청을 보내고 응답을 기다리다 타임아웃이 발생한 게이트웨이나 프락시에서 온 응답이다. |
| 505 |
HTTP Version Not Supported |
서버가 지원할 수 없거나 지원하지 않으려고 하는 버전의 프로토콜로 된 요청을 받았을 때 사용한다. |
[헤더]
헤더와 메서드는 클라이언트와 서버가 무엇을 하는지 결정하기 위해 함께 사용된다.
헤더는 특정 종류의 메시지에만 사용할 수 있는 헤더, 일반 목적으로 사용할 수 있는 헤더, 응답과 요청 메시지 양쪽 모두에서 정보를 제공하는 헤더가 있다.
헤더는 5가지로 분류된다.
1) 일반 헤더
| 헤더 |
설명 |
| Connection |
클라이언트와 서버가 요청/응답 연결에 대한 옵션을 정할 수 있게 해준다. |
| Date |
메시지가 언제 만들어졌는지에 대한 날짜와 시간을 제공한다. |
| MIME-Version |
발송자가 사용한 MIME의 버전을 알려준다. |
| Trailer chunked transfer |
인코딩으로 인코딩된 메시지의 끝 부분에 위치한 헤더들의 목록을 나열한다. |
| Transfer-Encoding |
수신자에게 안전한 전송을 위해 메시지에 어떤 인코딩이 적용되었는지 말해준다. |
| Upgrade |
발송자가 업그레이드하길 원하는 새 버전이나 프로토콜을 알려준다. |
| Via |
이 메시지가 어떤 중개자를 거쳐 왔는지 보여준다. |
일반 캐시 헤더
| 헤더 |
설명 |
| Cache-Control |
메시지와 함께 캐시 지지자를 전달하기 위해 사용한다. |
| Pragma |
메시지와 함께 지지자를 전달하는 또 다른 방법. 캐시에 국한되지 않는다.
(Cache-Control로 인해 deprecated 예정이다) |
2) 요청 헤더
요청 메시지에서만 의미를 갖는 헤더이다.
| 헤더 |
설명 |
| Client-IP |
클라이언트가 실행된 컴퓨터의 IP를 제공한다. |
| From |
클라잉너트 사용자의 메일 주소를 제공한다. |
| Host |
요청의 대상이 되는 서버의 호스트명과 포트를 제공한다. |
| Referer |
현재 요청 URI가 들어있었던 문서의 URL을 제공한다. |
| UA-Color |
클라이언트 기기 디스플레이의 색상 능력에 대한 정보를 제공한다. |
| UA-CPU |
클라이언트 CPU의 종류나 제조사를 알려준다. |
| UA-Disp |
클라이언트의 디스플레이 능력에 대한 정보를 제공한다. |
| UA-OS |
클라이언트 기기에서 동작 중인 운영체제의 이름과 버전을 알려준다. |
| UA-Pixels |
클라이언트 기기 디스플레이에 대한 픽셀 정보를 제공한다. |
| User-Agent |
요청을 보낸 애플리케이션의 이름을 서버에게 말해준다. |
Accept 관련 헤더
클라이언트는 Accept 관련 헤더를 이용해 서버에게 자신의 선호와 능력을 알려줄 수 있다.
| 헤더 |
설명 |
| Accept |
서버에게 서버가 보내도 되는 미디어 종류를 말해준다. |
| Accept-Charset |
서버에게 서버가 보내도 되는 문자 집합을 말해준다. |
| Accept-Encoding |
서버에게 서버가 보내도 되는 인코딩을 말해준다. |
| Accept-Language |
서버에게 서버가 보내도 되는 언어를 말해준다. |
| TE(Transfer-Encoding) |
서버에게 서버가 보내도 되는 확장 전송 코딩을 말해준다. |
조건부 요청 헤더
클라이언트는 요청에 제약을 넣기도 한다.
| 헤더 |
설명 |
| Expect |
클라이언트가 요청에 필요한 서버의 행동을 열거할 수 있게 해준다. |
| If-Match |
문서의 엔티티 태그가 주어진 엔티티 태그와 일치하는 경우에만 문서를 가져온다. |
| If-Modified-Since |
주어진 날짜 이후에 리소스가 변경되지 않았다면 요청을 제한한다. |
| If-None-Match |
문서의 엔티티 태그가 주어진 엔티티 태그와 일치하지 않는 경우에만 문서를 가져온다. |
| If-Range |
문서의 특정 범위에 대한 요청을 할 수 있게 해준다. |
| If-Unmodified-Since |
주어진 날짜 이후에 리소스가 변경되었다면 요청을 제한한다. |
| Range |
서버가 범위 요청을 지원한다면 리소스에 대한 특정 범위를 요청한다. |
요청 보안 헤더
HTTP는 자체적으로 요청을 위한 간단한 인증 요구/응답 체계를 갖고 있다.
이는 요청하는 클라이언트가 어느정도의 리소스에 접근하기 전에 자신을 인증하게 함으로써 트랜잭션을 더 안전하게 만들고자 하기 위함이다.
| 헤더 |
요청 |
| Authorization |
클라이언트가 서버에게 제공하는 인증 그 자체에 대한 정보를 담고 있다. |
| Cookie |
클라이언트가 서버에게 토큰을 전달할 때 사용한다. |
| Cookie2 |
요청자가 지원하는 쿠키의 버전을 알려줄 때 사용한다. |
프락시 요청 헤더
인터넷에서 프락시가 점점 흔해지면서 그들의 기능을 돕기 위해 몇몇 헤더들이 정의되어 왔다.
| 헤더 |
설명 |
| Max-Forwards |
요청이 원 서버로 향하는 과정에서 다른 프락시나 게이트웨이로 전달될 수 있는 최대 횟수.
TRACE 메서드와 함께 사용된다. |
| Proxy-Authorization |
Authorization과 같으나 Proxy에서 인증할 때 사용된다. |
| Proxy-Connection |
Connection과 같으나 Proxy에서 연결을 맺을 때 사용된다. |
3) 응답 헤더
응답헤더는 클라이언트에게 부가 정보를 제공한다.
| 헤더 |
설명 |
| Age |
응답이 얼마나 오래되었는지 |
| Public |
서버가 특정 리소스에 대해 지원하는 요청 메서드의 목록 |
| Retry-After |
현재 리소스가 사용 불가능한 상태일 때 언제 가능해지는지에 대한 날짜, 시각 |
| Server |
서버 애플리케이션의 이름과 버전 |
| Title |
HTML 문서에서 주어진 것과 같은 제목 |
| Warning |
사유 구절에 있는 것보다 더 자세한 경고메시지 |
협상 헤더
서버에 프랑스어와 독일어로 번역된 HTML 문서가 있는 경우와 같이 여러가지 표현이 가능한 상황이라면, 서버와 클라이언트가 어떤 표현을 택할 것인지에 대한 협상을 할 수 있도록 지원한다.
| 헤더 |
설명 |
| Accept-Ranges |
서버가 자원에 대해 받아들일 수 있는 범위의 형태 |
| Vary |
서버가 확인해봐야 하고, 그렇기 때문에 응답에 영향을 줄 수 있는 헤더들의 목록
예시) 서버가 클라이언트에게 보내줄 리소스의 가장 적절한 버전을 선택하기 위해 살펴보아야 하는 헤더들의 목록 |
응답 보안 헤더
기본적인 인증 요구 헤더이다.
Set-Cookie와 Set-Cookie2는 확장헤더이다.
| 헤더 |
설명 |
| Proxy-Authenticate |
프락시에서 클라이언트로 보낸 인증요구의 목록 |
| Set-Cookie |
진짜 보안 헤더는 아니지만, 보안에 영향을 줄 수 있다.
서버가 클라이언트를 인증할 수 있도록 클라이언트 측에 토큰을 설정하기 위해 사용한다. |
| Set-Cookie2 |
Set-Cookie와 비슷하게 RFC 2965로 정의된 쿠키 |
| WWW-Authenticate |
서버에서 클라이언트로 보낸 인증 요구의 목록 |
4) 엔티티 헤더
요청과 응답 양쪽 모두에 엔티티를 포함할 수 있기 때문에, 이 헤더들은 양 타입의 메시지에 모두 나타날 수 있다.
엔티티 헤더는 엔티티와 그것의 내용물에 대한 개체의 타입부터 시작해서 주어진 리소스에 대해 요청할 수 있는 유효한 메서드들까지 광범위한 정보를 제공한다. 일반적으로 엔티티 헤더는 메시지의 수신자에게 자신이 다루고 있는 것이 무엇인지 말해준다.
| 헤더 |
설명 |
| Allow |
이 엔터티에 대해 수행될 수 있는 요청 메서드들을 나열한다. |
| Location |
클라이언트에게 엔티티가 실제로 어디에 위치하고 있는지 말해준다.
수신자에게 리소스에 대한 위치(URL)를를 알려줄 때 사용한다. |
콘텐츠 헤더
콘텐츠 헤더는 엔티티 콘텐츠에 대한 구체적인 정보를 제공한다. 콘텐츠의 종류, 크기, 기타 컨텐츠를 처리할 때 유용하게 활용될 수 있는 것들이다.
| 헤더 |
설명 |
| Content-Base |
본문에서 사용된 상대 URL을 계산하기 위한 기저 URL |
| Content-Encoding |
본문에 적용된 어떤 인코딩 |
| Content-Language |
본문을 이해하는데 가장 적절한 자연어 |
| Content-Length |
본문의 길이나 크기 |
| Content-Location |
리소스가 실제로 어디에 위치하는지 |
| Content-MD5 |
본문의 MD5 체크섬 |
| Content-Range |
전체 리소스에서 이 엔티티가 해당하는 범위를 바이트 단위로 표현 |
| Content-Type |
이 본문이 어떤 종류의 객체인지 |
엔티티 캐싱 헤더
일반 캐싱 헤더는 언제, 어떻게 캐시가 되어야 하는지에 대한 지시자를 제공한다.
엔티티 캐싱 헤더는 엔티티 캐싱에 대한 정보를 제공한다. 이는 리소스에 대해 캐시된 사본이 유효한지에 대한 정보와 유효하지 않게 되는 시점을 추정하기 위한 단서 같은 것이다.
| 헤더 |
설명 |
| ETag |
이 엔티티에 대한 엔티티 태그 |
| Expires |
이 엔티티가 더 이상 유효하지 않아 원본을 다시 받아와야 하는 일시 |
| Last-Modified |
가장 최근 이 엔티티가 변경된 일시 |
5) 확장 헤더
확장 헤더는 애플리케이션 개발자들에 의해 만들어졌지만 아직 승인된 HTTP 명세에는 추가되지 않은 비표준 헤더이다.