HTTP 프로토콜의 리퀘스트와 리스폰스에는 반드시 메세지 헤더가 포함되어 있는데,
메세지 헤더에는 클라이언트나 서버가 리퀘스트나 리스폰스를 처리하기 위한 정보가 들어있다.
Request의 메세지 헤더
- 리퀘스트 라인 : 메소드, URI, HTTP 버전
- 리퀘스트 헤더 필드
- 일반 헤더 필드
- 엔티티 헤더 필드
- 그 외
Response의 메세지 헤더
- 상태라인 : HTTP 버전, 상태 코드
- 리스폰스 헤더 필드
- 일반 헤더 필드
- 엔티티 헤더 필드
- 그 외
HTTP 헤더 필드
HTTP 헤더 필드는 HTTP 메세지를 구성하는 요소 중 하나로
서버 간의 통신에서 리퀘스트와 리스폰스 모두 사용되고 있고, 부가적으로 중요한 정보를 전달하는 역할을 담당한다.
HTTP 헤더 필드의 구조
- 헤더 필드 명 : 필드 값
ex) Content-Type:text/html
4종류의 HTTP 헤더 필드
- 일반적 헤더 필드(General Header Fields)
리퀘스트 메세지와 리스폰스 메세지 둘 다 사용되는 헤더 - 리퀘스트 헤더 필드(Request Header Fields)
클라이언트 --> 서버 측으로 송신된 리퀘스트 메세지에 사용되는 헤더
리퀘스트의 부가적 정보, 클라이언트의 정보, 콘텐츠에 관한 우선 순위 등을 부가 - 리스폰스 헤더 필드(Response Header Fields)
서버 --> 클라이언트 측으로 송신한 리스폰스 메세지에 사용되는 헤더
리스폰스의 부가적 정보, 클라이언트의 추가 정보 요구 등을 부가 - 엔티티 헤더 필드(Entity Header Fields)
리퀘스트 메세지와 리스폰스 메세지에 포함된 엔티티에 사용되는 헤더
콘텐츠 갱신 시간 등의 엔티티에 관한 정보를 부가
End-to-end 헤더와 Hop-by-hop 헤더
HTTP 헤더 필드는 캐시와 비캐시 프록시의 동작을 정의하기 위해서 두 가지 카테고리로 분류한다.
- End-to-end 헤더
이 카테고리에 분류된 헤더는 리퀘스트나 리스폰스의 최종 수신자에게 전송된다.
캐시에서 구축된 리스폰스 중 보존해야 하고, 다시 전송되지 않으면 안되도록 되어 있다. - Hop-by-hop 헤더
이 카테고리에 분류된 헤더는 한 번 전송에 대해서만 유효하고 캐시와 프록시에 의해서 전송되지 않는 것도 있다.
HTTP/1.1과 그 이후에서 사용되는 Hop-by-hop 헤더는 Connection 헤더 필드에 열거해야 한다.
HTTP/1.1에서 Hop-by-hop 헤더
여기에 열거하는 8개의 헤더 필드 이외에는 모두 End-to-end 헤더에 분류된다.
- Connection
- Keep-Alive
- Proxy-Authenticate
- Proxy-Authorization
- Trailer
- TE
- Transfer-Encoding
- Upgrade
HTTP/1.1 일반 헤더 필드
- Cache-Control
Cache-Control 헤더는 디렉티브로 불리는 명령을 사용하여 캐싱 동작을 지정한다. - Connection
다음의 두 가지 역할을 한다. : 프록시에 더 이상 전송하지 않는 헤더 필드를 지정, 지속적 접속 관리
Connection : 더 이상 존재하지 않는 헤더 필드 명
-> 프록시 서버에 더 이상 전송하지 않는 헤더 필드(hop-by-hop 헤더)를 지정할 수 있다.
Connection : Close
-> 서버 측에서 명시적으로 접속을 끊고 싶은 경우에 사용한다.
Connection : Keep-Alive
-> 오래된 버전의 HTTP에서 지속적 접속을 하고 싶은 경우에 Keep-Alive라고 지정해야 한다.
(HTTP 1.1 이전 버전에서는 지속적 접속이 디폴트가 아니었다.) - Date
HTTP 메세지를 생성한 날짜를 나타낸다. - Pragma
HTTP/1.1 보다 오래된 버전의 흔적으로 HTTP/1.0 과의 후방 호환성만을 위해서 정의되어 있는 헤더 필드다.
지정할 수 있는 형식은 다음과 같이 1개 뿐이다.
Pragma : no-cache
이 헤더 필드는 일반 헤더 필드이지만 클라이언트의 리퀘스트에서만 사용된다.
클라이언트는 캐시된 리소스의 리스폰스를 원하지 않음을 모든 중간 서버에 알리기 위해 사용한다. - Trailer
메세지 바디의 뒤에 기술되어 있는 헤더 필드를 미리 전달 할 수 있다.
이 헤더 필드는 HTTP/1.1에 구현되어 있는 청크 전송 인코딩을 사용하고 있는 경우에 사용 가능하다. - Trailer-Encoding
메세지 바디의 전송 코딩 형식을 지정하는 경우에 사용된다. - Upgrade
HTTP 및 다른 프로토콜의 새로운 버전이 통신에 이용 되는 경우에 사용된다. - Via
클라이언트와 서버 간의 리퀘스트 혹은 리스폰스 메세지의 경로를 알기 위해서 사용된다.
프록시 혹은 게이트웨으는 자신의 서버 정보를 Via 헤더 필드에 추가한 뒤에 메세지를 전송한다. - Warning
HTTP/1.0 리스폰스 헤더가 HTTP/1.1에서 변경된 것으로, 리스폰스에 관한 추가 정보를 전달한다.
기본적으로 캐시에 관한 문제의 경고를 유저에게 전달한다.
Warning 헤더 형식
Warning: [경고 코드][경고한 호스트:포트 번호]"[경고문]" ([날짜])
리퀘스트 헤더 필드
- Accept
유저 에이전트에 처리할 수 있는 미디어 타입과 미디어 타입의 상대적인 우선 순위를 전달하기 위해서 사용된다. - Accept-Charset
유저 에이전트에서 처리할 수 있는 문자셋으로, 문자셋의 상대적인 우선 순위를 전달하기 위해서 사용된다.
문자셋은 한 번에 여러 개를 지정할 수 있다. - Accept-Encoding
유저 에이전트가 처리할 수 있는 콘텐츠 코딩과 콘텐츠 코딩의 상대적인 우선 순위를 전달하기 위해서 사용된다.
콘텐츠 코딩의 지정은 한번에 여러 개를 지정할 수 있다. - Accept-Language
유저 에이전트가 처리할 수 있는 자연어와 자연어의 상대적인 우선 순위를 전달하기 위해서 사용된다.
자연어 세트는 한 번에 여러 개를 지정할 수 있다. - Authorization
유저 에이전트의 인증 정보를 전달하기 위해서 사용된다. - Expect
클라리언트가 서버에 특정 동작 요구를 전달한다. - From
유저 에이전트를 사용하고 있는 유저의 메일 주소를 전달한다. - Host
리퀘스트한 리소스의 인터넷 호스트와 포트 번호를 전달한다.
Host 헤더 필드는 HTTP/1.1에서 유일한 필수 헤더 필드이다.
Host 헤더 필드가 존재하는 이유는 1대의 서버에서 복수의 도메인을 할당할 수 있는
가상 호스트의 구조와 깊은 관련이 있다.
같은 IP 주소로 복수의 도메인이 적용되어 있으면 어느 도메인에 대한 리퀘스트인지 알 수가 없다.
그래서 Host 헤더 필드에 리퀘스트를 받을 호스트명을 명확하게 해둘 필요가 있다. - If-Match
조건부 리퀘스트라고 부른다. 서버는 지정된 조건에 맞는 경우에만 리퀘스트를 받는다. - If-Modified-Since
조건부 리퀘스트의 하나로 리소스가 갱신 날짜가 필드 값보다 새롭지 않다면 리퀘스트를 받아들인다. - If-None-Match
조건부 리퀘스트의 하나로 If-Match 헤더 필드와는 반대로 동작한다.
서버는 If-None-Match 필드 값과 ETag가 일치하지 않은 경우만 리퀘스트를 받아들인다. - If-Range
조건부 리퀘스트의 하나로 If-Range로 지정한 필드 값과 지정한 리소스의 ETag 값 혹은 날짜가 일치하면
Range 리퀘스트로서 처리하고 싶다는 것을 전달한다. 일치하지 않는 경우에는 리소스 전체를 반환한다. - If-Unmodified-Since
If-Modified-Since 헤더 필드와 반대로 동작 한다.
지정된 리소스가 필드 값에 지정된 날짜 이후에 갱신되어 있지 않은 경우에만 리퀘스트를 받아들인다. - Max-Forwards
Trace 혹은 Options 메소드에 의한 리퀘스트를 할 때에 전송해도 좋은 서버 수의 최대치를 10진수 정수로 지정한다.
HTTP를 사용한 통신에서는 리퀘스트가 프록시 서버 등 여러 대의 서버를 경유해 가는 경우가 있는데,
도중에 프록시 서버에서 무언가의 원인으로 리퀘스트 전송이 실패하게 되면 클라이언트는 알 수가 없다.
이러한 문제가 발생한 경우 원인 조사에 Max-Forwards 헤더 필드가 활용된다.
필드 값이 0이 되었던 서버가 리스폰스를 하기 때문에 그 서버까지의 상황을 알 수 있다. - Proxy-Authorization
프록시 서버에서의 인증 요구를 받아들인 때에 인증에 필요한 클라이언트의 정보를 전달한다. - Range
리소스의 일부분만 취득하는 Range 리퀘스트를 할 때 지정 범위를 전달한다. - Referer
리퀘스트가 발생한 본래 리소스의 URI를 전달한다.
기본적으로는 보내져야 하지만, 브라우저의 주소창에 직접 URI를 입력한 경우와
보안상 바람직하지 않다고 판단된 경우에는 보내지 않아도 괜찮다. - TE
리스폰스로 받을 수 있는 전송 코딩의 형식과 상대적인 우선 순위를 전달한다. - User-Agent
리퀘스트를 생성한 브라우저와 유저 에이전트의 이름 등을 전달하기 위한 필드이다.
리스폰스 헤더 필드
- Accept-Ranges
서버가 리소스의 일부분만 지정해서 취득할 수 있는 Range 리퀘스트를 접수할 수 있는지 여부를 전달한다. - Age
얼마나 오래 전에 오리진 서버에서 리스폰스가 생성되었는지를 전달한다. - ETag
엔티티 태그라고 불리며 일의적으로 리소스를 특정하기 위한 문자열을 전달한다. - Location
리스폰스의 수신자에 대해서 Request-URI 이외의 리소스 액세스를 유도하는 경우에 사용된다. - Proxy-Authenticate
프록시 서버에서의 인증 요구를 클라이언트에 전달한다. - Retry-After
클라이언트가 일정 시간 후에 리퀘스트를 다시 시행해야 하는지를 전달한다. - Server
서버에 설치되어 있는 HTTP 서버의 소프트웨어를 전달한다.
단순히 서버의 소프트웨어 명칭만이 아닌, 버전이나 옵션에 대해서도 기재하는 경우가 있다. - Vary
캐시를 컨트롤하기 위해서 사용한다.
오리진 서버가 프록시 서버에 로컬 캐시를 사용하는 방법에 대한 지시를 전달한다. - WWW-Authenticate
HTTP 엑세스 인증에 사용되는데 Request-URI에 지정했던 리소스에 적용할 수 있는 인증 스키마와
파라미터를 나타내는 challenge를 전달한다.
엔티티 헤더 필드
- Allow
Request-URI에 지정된 리소스가 제공하는 메소드를 전달한다. - Content-Encoding
서버가 엔티티 바디에 대해서 실시한 콘텐츠 코딩 형식을 전달한다. - Content-Language
엔티티 바디에 사용된 자연어를 전달한다. - Content-Length
엔티티 바디의 크기를 전달한다. - Content-Location
메세지 바디에 대응하는 URI를 전달한다. - Content-MD5
메세지 바디가 변경되지 않고 도착했는지 확인하기 위해 MD5 알고리즘에 의해서 생성된 값을 전달한다. - Content-Range
범위를 지정해서 일부분만을 리퀘스트하는 Range 리퀘스트에 대해서 리스폰스를 할 때에 사용된다. - Content-Type
엔티티 바디에 포함되는 오브젝트의 미디어 타입을 전달한다. - Expires
리소스의 유효 기한 날짜를 전달한다. - Last-Modified
리소스가 마지막으로 갱신되었던 날짜 정보를 전달한다.
쿠키를 위한 헤더 필드
- Set-Cookie
서버가 클라이언트에 대해서 상태 관리를 시작할 때 다양한 정보를 전달한다.
필드 값에는 다음과 같은 정보가 기술된다.
1. Expires 속성 : 쿠키 유효 기간 (지정되지 않은 경우는 브라우저를 닫을 때까지)
2. Path 속성 : 쿠키 적용 대상이 되는 서버 상의 디렉토리(지정하지 않은 경우는 도큐먼트와 같음)
3. Domain 속성 : 쿠키 적용 대상이 되는 도메인 명(지정하지 않은 경우는 쿠키를 생성한 서버의 도메인)
4. Secure 속성 : HTTPS로 통신하고 있는 경우에만 쿠키를 송신
5. HttpOnly 속성 : 쿠키를 JavaScript에서 액세스하지 못하도록 제한 - Cookie
클라이언트가 HTTP의 상태 관리 지원을 원할 때 서버로부터 수신한 쿠키를 이후의 리퀘스트에 포함해서 전달한다.
쿠키를 여러 개 수신하고 있을 때에는 쿠키를 여러 개 보내는 것도 가능하다.
그 이외의 헤더 필드
- X-Frame-Option
다른 웹 사이트의 프레임에서 표시를 제어하는 HTTP 리스폰스 헤더로
클릭 재킹이라는 공격을 막는 것을 목적으로 한다. - X-XSS-Protection
크로스 사이트 스크립팅(XSS) 대책으로서 브라우저의 XSS 보호 기능을 제어하는 HTTP 리스폰스 헤더이다. - DNT
Do Not Track라는 뜻이며 개인 정보 수집을 거부하는 의사를 나타내는 HTTP 리퀘스트 헤더이다. - P3P
웹 사이트 상의 프라이버시 정책에 P3P를 사용하는 것으로,
프로그램이 읽을 수 있는 형태로 나타내기 위한 HTTP 리스폰스 헤더이다.
참고 : 그림으로 배우는 Http&Network Basic
'CS > Network' 카테고리의 다른 글
| 제 7장 웹을 안전하게 지켜주는 HTTPS (0) | 2023.08.31 |
|---|---|
| 제 5장 HTTP와 연계하는 웹 서버 (0) | 2023.04.16 |
| 제 4장 결과를 전달하는 HTTP 상태 코드 (0) | 2023.04.06 |
| 제 3장 HTTP 정보는 HTTP 메세지에 있다. (0) | 2023.03.27 |
| 제 2장 간단한 프로토콜 HTTP (0) | 2023.03.27 |