Post

[Book - 그림으로 배우는 Http & Network Basic] 6. HTTP 헤더

Posted Updated
By Yn3 28 min read

HTTP 메시지 헤더

HTTP 메시지 헤더

HTTP 프로토콜의 Request와 Response에는 반드시 메시지 헤더가 포함되어 있다.

  • Request의 HTTP 메시지 구성

    메소드, URI, HTTP 버전, HTTP 헤더 필드 등

  • Response의 HTTP 메시지 구성

    HTTP 메시지와 HTTP 버전, 상태 코드(코드와 설명), HTTP 헤더 필드 등

헤더 필드는 Request와 Response 양쪽 모두 존재하는데 HTP 메시지에 관한 정보를 가지고 있다.

HTTP 헤더 필드

중요한 정보 전달

HTTP 헤더 필드는 HTTP 메시지를 구성하는 요소의 하나이고, 부가적으로 중요한 정보를 전달하는 역할을 담당하고 있다.

HTTP 헤더 필드의 구조

헤더 필드 명 : 필드 값

HTTP 헤더 필드가 중복된 경우 브라우저에 따라 최초의 헤더 필드를 우선적으로 처리하거나, 마지막 헤더 필드를 우선적으로 처리한다.

4종류의 HTTP 헤더 필드

HTTP 헤더 필드는 용도에 따라 4종류로 분류된다.

  • 일반적 헤더 필드 (General Header Fields)

    Request 메시지와 Response 메시지 둘 다 사용되는 헤더이다.

  • 리퀘스트 헤더 필드 (Request Header Fields)

    클라이언트에서 서버로 송신된 Request 메시지에 사용되는 헤더이다.

  • 리스폰스 헤더 필드 (Response Header Fields)

    서브에서 클라이언트로 송신한 Response 메시지에 사용되는 헤더이다.

  • 엔티티 헤더 필드 (Entity Header Fields)

    Request메시지와 Response 메시지에 포함된 엔티티에 사용되는 헤더이다.

    콘텐츠 갱신 시간 등의 엔티티에 관한 정보를 부가한다.

End-to-end 헤더와 Hop-by-hop 헤더

HTTP 헤더 필드는 캐시와 비캐시 프록시의 동작을 정의하기 위해서 두 가지 카테고리로 분류되어 있다.

  • End-to-end 헤더

    Request나 Response의 최종 수신자에게 전송된다.

    캐시에서 구축된 Response 중 보존되어야 하고, 다시 전송되지 않으면 안되도록 되어 있다.

  • Hop-by-hop 헤더

    한 번 전송에 대해서만 유효하고, 캐시와 프록시에 의해서 전송되지 않는 것도 있다.

    HTTP/1.1과 그 이후에서 사용되는 Hop-by-hop 헤더는 Connection 헤더 필드에 열거해야 한다.
    아래 8개의 헤더 필드는 Hop-by-hop 헤더에 분류되지만, 이외에는 모두 End-by-end 헤더에 분류된다.
    Connection
    Keep-Alive
    Proxy-Authenticate
    Proxy-Authorization
    Trailer
    TE
    Transfer-Encoding
    Upgrade

HTTP/1.1 일반 헤더 필드

일반 헤더 필드는 Request 메시지와 Response 메시지 양쪽에서 사용되는 헤더이다.

헤더 필드 명설명
Cache-Control캐싱 동작 지정
ConnectionHop-by-hop 헤더, 커넥션 관리
Date메시지 생성 날짜
Pragma메시지 제어
Trailer메시지의 끝에 있는 헤더의 일람
Transfer-Encoding메시지 바디의 전송 코딩 형식 지정
Upgrade다른 프로토콜에 업그레이드
Via프록시 서버에 관한 정보
Warning에러 통지

Cache-Control

디렉티브로 불리는 명령을 사용하여 캐싱 동작을 지정한다.

Cache-Control 디렉티브

  • Cache Request
  • Cache Response

캐시가 가능한지 여부를 나타내는 디렉티브

  • public 디렉티브

    Cache-Control: public

    다른 유저에게도 돌려줄 수 있는 캐시를 해도 좋다는 것을 명시적으로 나타낸다.

  • private 디렉티브

    Cache-Control: private

    Response는 특정 유저만을 대상으로 하고 있다는 것을 나타낸다.

  • no-cache 디렉티브

    Cache-Control: no-cache

    캐시로부터 오래된 리소스가 반환되는 것을 막기 위해 사용된다.

    캐시된 Response를 클라이언트가 받아 들이지 않고, 중간 캐시 서버가 오리진 서버까지 Request를 전송해야 한다.
    Cache-Control: no-cache=Location

    지정된 헤더 필드 이외에는 캐시하는 것이 가능하다.

    이 파라미터는 Response 디렉티브만 사용 가능하다.

캐시로 보존 가능한 것을 제어하는 디렉티브

  • no-store 디렉티브

    Cache-Control: no-store

    Request 혹은 Response에 기밀 정보가 포함되어 있음을 나타낸다.

    따라서 캐시는 Request, Response의 일부분을 로컬 스토리지에 보전해서는 안 되도록 지정한다.

캐시 기한이나 검증을 지정하는 디렉티브

  • s-maxage 디렉티브

    Cache-Control: s-maxage=604800 (단위: 초)

    max-age 디렉티브와 기능은 같지만, 여러 유저가 이용 할 수 있는 공유 캐시 서버에만 적용된다는 것이 다르다.

    같은 유저에 반복해서 Response를 반환하는 캐시 서버는 무효한 디렉티브이다.

    s-maxage 디렉티브 사용 시 Expires 헤더 필드와 max-age 디렉티브는 무시된다.

  • max-age 디렉티브

    Cache-Control: max-age=604800 (단위: 초)

    max-age 디렉티브

    클라이언트의 Request에서 사용된 경우, 지정되었던 값 보다 새로운 경우에는 캐시되었던 리소스를 받아들일 수 있다.

    서버의 Response에서 사용된 경우, 캐시 서버가 유효성의 재확인을 하지 않고 리소스를 캐시에 보존해 두는 최대 시간을 나타낸다.

    동시에 Expires 헤더 필드가 달린 경우
    HTTP/1.1 캐시 서버: max-age 디렉티브의 지정 우선, Expires 헤더 필드 무시
    HTTP/1.0 캐시 서버: 위와 반대

  • min-fresh 디렉티브

    Cache-Control: min-fresh=60 (단위: 초)

    캐시된 리소스가 적어도 지정된 시간은 최신 상태의 것을 반환하도록 캐시 서버에 요구한다.

  • max-stale 디렉티브

    Cache-Control: max-stale=3600 (단위: 초)

    캐시된 리소스의 유효 기한이 끝났더라도 받아들일 수 있음을 나타낸다.

  • only-if-cached 디렉티브

    Cache-Control: only-if-cached

    캐시 서버에서 Response의 리로드와 유효성을 재확인하지 않도록 요구한다.

    캐시 서버가 로컬 캐시로부터 응답할 수 없는 경우에는 “504 Gateway Timeout” 상태를 반환한다.

  • must-revalidate 디렉티브

    Cache-Control: must-revalidate

    Response의 캐시가 현재도 유효한지 아닌지의 여부를 오리진 서버에 조회를 요구한다.

    프록시가 오리진 서버에 도달할 수 없고, 리소스를 다시 요구할 수 없는 경우에는 캐시는 클라이언트에 504(Gateway Timeout)를 반환한다.
    Request에서 max-stale 디렉티브를 사용하고 있더라도 무시한다.

  • proxy-revalidate 디렉티브

    Cache-Control: proxy-revalidate

    모든 캐시 서버에 대해서 이후의 Request로 해당 Response를 반환할 때는 반드시 유효성 재확인을 하도록 요구한다.

  • no-transform 디렉티브

    Cache-Control: no-transform

    캐시가 엔티티 바디의 미디어 타입을 변경하지 않도록 지정한다.

Cache-Control 확장

  • cache-extension 토큰

    Cache-Control: private, community="UCI"

    디렉티브를 확장할 수 있다.

Connection

Connection 헤더 필드의 역할

  • 프록시에 더 이상 전송하지 않는 헤더 필드를 지정
  • 지속적 접속 관리

프록시에 더 이상 전송하지 않는 헤더 필드를 지정

Connection 헤더 필드

Connection: 더 이상 전송하지 않는 헤더 필드 명

프록시 서버에 더 이상 전송하지 않는 헤더 필드(hop-by-hop 헤더)를 지정할 수 있다.

지속적 접속 관리

클라이언트가 Request를 보낸 경우 서버에서 Connection 헤더 필드를 Response 한다.

  • 서버 측에서 명시적으로 접속을 끊고 싶을 경우

    Connection: Close

  • 오래된 버전의 HTTP에서 지속적 접속을 하고 싶은 경우

    Connection: Keep-Alive

Date

HTTP 메시지를 생성한 날짜를 나타낸다.

Pragma

HTTP/1.0 와의 후방 호환성만을 위해서 정의되어 있는 헤더 필드이다.

Pragma: no-cache

클라이언트의 Request에서만 사용되고, 클라이언트는 캐시된 리소스의 Response를 원하지 않음을 모든 중간 서버에 알리기 위해 사용된다.

모든 중간 서버가 HTTP/1.1을 기준으로 구성되어 있다면 캐시 동작 지정은 Cache-Control: no-cache를 사용하는 것이 바람직하다.

Trailer

메시지 바디의 뒤에 기술되어 있는 헤더 필드를 미리 전달할 수 있다.

HTTP/1.1에 구현되어 있는 청크 전송 인코딩을 사용하고 있는 경우에

사용 가능하다.

Transfer-Encoding

메시지 바디의 전송 코딩 형식을 지정하는 경우에 사용된다.

Upgrade

HTTP 및 다른 프로토콜의 새로운 버전이 통신에 이용되는 경우에 사용된다.

Upgrade 헤더 필드에 의해서 업그레이드 되는 대상은 클라이언트와 인접한 서버 사이뿐이기 때문에 Upgrade 헤더 필드를 사용하는 경우는 Connection: Upgrade도 지정할 필요가 있다.

Via

Via

클라이언트와 서버 간의 Request 혹은 Response 메시지의 경로를 알기 위해서 사용된다.

전송된 메시지의 추적과 Request 루프의 회피 등에 사용되기 때문에 프록시를 경유하는 경우에는 반드시 부가할 필요가 있다.

Warning

Response에 관한 추가 정보를 전달한다. (기본적으로 캐시에 관한 문제의 경로를 유저에 전달한다.)

Warning: [경고 코드] [경고한 호스트:포트 번호]"[경고문]" ([날짜])

리퀘스트 헤더 필드

Accept

Accept: text/html, application/xhtml+xml, application/xml/xml;q=0.9, */*;q=0.8

유저 에이전트에 처리할 수 있는 미디어 타입과 미디어 타입의 상대적인 우선 순위를 전달하기 위해서 사용된다.

  • 텍스트 파일

    text/html, text/plain, text/css, …

    application/xhtml+xml, application/xml, …

  • 이미지 파일

    image/jpeg, image/gif, image/png, …

  • 동영상 파일

    video/mpeg, video/quicktime, …

  • 애플리케이션용 바이너리 파일

    application/octet-stream, application/zip, …

Accept-Charset

Accept-Charset:iso-8859-5, unicode-1-1:q+0.8

유저 에이전트에서 처리할 수 있는 문자셋으로, 문자셋의 상대적인 우선 순위를 전달하기 위해서 사용된다.

서버 구동형 네고시에이션에 이용된다.

Accept-Encoding

Accept-Encoding: gzip, deflate

유저 에이전트가 처리할 수 있는 콘텐츠 코딩과 콘텐츠 코딩의 상대적인 우선 순위를 전달하기 위해서 사용된다.

  • gzip

    파일 압축 프로그램 gzip(GNU zip)에서 생성된 인코딩 포맷

  • compress

    UNIX 파일 압축 프로그램 “compress”에 의해서 만들어진 인코딩 포맷

  • deflate

    Zlib 포맷과 deflate 압축 알고리즘에 의해서 만들어진 인코딩 포맷을 조합한 것

  • identity

    압축과 변형을 하지 않는 디폴트 인코딩 포맷

Accept-Language

Accept-Language: ko-kr, en-us;q=0.7, en;q=0.3

유저 에이전트가 처리할 수 있는 자연어의 세트(한국어와 영어라는 의미)와 자연어 세트의 상대적인 우선 순위를 전달하기 위해서 사용된다.

Authorization

Athorization: Basic [인증 정보]

서버에 인증을 받으려 하는 유저 에이전트는 상태 코드 401 Response 뒤에 Request에 Authorization 헤더 필드를 포함한다.

Expect

Expect: 100-continue

클라이언트가 서버에 특정 동작 요구를 전달한다.

From

From: [email 주소]

유저 에이전트를 사용하고 있는 유저의 메일 주소를 전달한다.

Host

Host: [도메인 주소]

Request한 리소스의 인터넷 호스트와 포트 번호를 전달한다.

Host 헤더 필드가 존재하는 이유는 1대의 서버에서 복수의 도메인을 할당할 수 있는 가상 호스트의 구조와 매우 깊은 관련이 있다.

If-Match

조건부 Request라고 부른다.

If-Match

서버는 If-Match의 필드 값과 리소스의 ETag 값이 일치한 경우에만 Request를 받아들일 수 있다.

If-Modified-Since

리소스가 갱신 날짜가 필드 값보다 새롭지 않다면 Request를 받아들이겠다는 뜻을 전달한다.

If-None-Match

If-None-Match 필드 값고 ETag가 일치하지 않은 경우만 Request를 받아들인다.

If-Match 헤더 필드와는 반대로 동작을 한다.

이 헤더 필드를 사용함으로써 최신의 리소스를 요구한다.

If-Range

조건부 Request의 하나로 If-Range로 지정한 필드값(ETag 값, 혹은 날짜를 지정)과 지정한 리소스의 ETag 값 혹은 날짜가 일치하면 Range Request로서 처리하고 싶다는 것을 전달한다.

일치하지 않는 경우에는 리소스 전체를 반환한다.

If-Unmodified-Since

지정된 리소스가 필드 값에 지정된 날짜 이후에 갱신되어 있지 않는 경우에만 Request를 받아들이도록 전달한다.

Max-Forwards

Max-Forwards

받아넘길 때마다 Max-Forwards 값을 1씩 뺀다.

값이 0이 되면 Response를 반환한다.

Proxy-Authorization

Proxy-Authorization: Basic [인증 정보]

프록시 서버에서의 인증 요구를 받아들인 때에 인증에 필요한 클라이언트의 정보를 전달한다.

클라이언트와 프록시 사이에서 인증이 이루어진다.

Range

Range: ytes=5001-10000

리소스의 일부분만 취득하는 Range Request를 할 때 지정 범위를 전달한다.

Referer

Referer: [URI]

Request가 발생한 본래 리소스의 URI를 전달한다.

TE

TE: gzip, deflate;q=0.5

Response로 받을 수 있는 전송 코딩의 형식과 상대적인 우선 순위를 전달한다.

TE: trailers

전송 코딩의 지정 이외에 Trailer를 동반하는 청크 전송 인코딩 형식을 지정하는 것이 가능하다.

User-Agent

Request를 생성한 브라우저와 유저 에이전트의 이름 등을 전달하기 위한 필드이다.

리스폰스 헤더 필드

Accept-Ranges

Accept-Ranges: bytes

서버가 리소스의 일부분만 지정해서 취득할 수 있는 Range Request를 접수할 수 있는지 여부를 전달한다.

지정 가능한 경우에는 “bytes”, 수신 불가능한 경우에는 “none”이라고 기록한다.

Age

Age: 600

얼마나 오래 전에 오리진 서버에서 Response가 생성되었는지를 전달한다.

ETag

ETag: "[ETag 값]"

엔티티 태그라고 불리며, 일의적으로 리소스를 특정하기 위한 문자열을 전달한다.

  • 강한 ETag 값

    ETag: "[ETag 값]"

    엔티티가 아주 조금 다르더라도 반드시 값은 변화한다.

  • 약한 ETag 값

    ETag: W/"[ETag 값]"

    리소스가 같다는 것만을 나타낸다.

    의미가 다른 리소스로 그 차이가 있는 경우에만 ETag 값이 변화한다.

    값의 앞부분에 “W/” 가 붙는다.

Location

Response의 수신자에 대해서 Request-URI 이외의 리소스 액세스를 유도하는 경우에 사용된다.

강제로 리다이렉트 하는 곳의 리소스에 액세스를 시도한다.

Proxy-Authenticate

Proxy-Authenticate: Basic realm="[realm]"

프록시 서버에서의 인증 요구를 클라이언트에 전달한다.

클라이언트와 프록시 사이에서 인증이 이루어진다.

Retry-After

Retry-After: 120

클라이언트가 일정 시간 후에 Requeest를 다시 시행해야 하는지를 전달한다.

Server

서버에 설치되어 있는 HTTP 서버의 소프트웨어를 전달한다.

Vary

Vary

Vary: Accept-Language

캐시를 컨트롤하기 위해서 사용한다.

오리진 서버가 프록시 서버에 로컬 캐시를 사용하는 방법에 대한 지시를 전달한다.

WWW-Authenticate

WWW-Authenticate: Basic realm=”[realm]”

HTTP 액세스 인증에 사용되는데 Reqeust-URI에 지정했던 리소스에 적용할 수 있는 인증 스키마(”Basic, “Digest”)와 파라이커를 나타내는 challenge를 전달한다.

상태 코드 401 Unauthorized Response에 반드시 포함된다.

엔티티 헤더 필드

콘텐츠의 갱신 시간 같은 엔티티에 관한 정보를 포함한다.

Allow

Allow: GET, HEAD

Request-URI에 지정된 리소스가 제공하는 메소드의 일람을 전달한다.

Content-Encoding

Content-Encoding: gzip

서버가 엔티티 바디에 대해서 실시한 콘텐츠 코딩 형식을 전달한다.

  • 4가지 콘텐츠 코딩 형식

    Gzip

    Compress

    Deflate

    Identity

Content-Language

Content-Language: en

엔티티 바디에 사용된 자연어를 전달한다.

Content-Length

Content-Length: 15000

엔티티 바디의 크기(단위는 bytes)를 전달한다.

Content-Location

메시지 바디로 반환된 리소스의 URI를 나타낸다.

Content-MD5

Content-MD5

메시지 바디가 변경되지 않고 도착했는지 확인하기 위해 MD5 알고리즘에 의해서 생성된 값을 전달한다.

유효성을 확인하기 위해서는 수신한 클라이언트 측에서 메시지 바디에 같은 MD5 알고리즘을 실행한다. 이렇게 해서 도출한 값과 필드 값을 비교하여 메시지 바디가 올바른지 여부를 알 수가 있다.

악의를 가진 변조는 검출할 수 없다.

Content-Range

Content-Range

Content-Range: bytes 5001-10000/10000

범위를 지정해서 일부분만을 Request하는 Range Request에 대해서 Response를 할 때에 사용된다.

Content-Type

Content-Type: text/html; charset=UTF-8

엔티티 바디에 포함되는 오브젝트의 미디어 타입을 전달한다.

Expires

리소스의 유효 기한 날짜를 전달한다.

Last-Modified

리소스가 마지막으로 갱싱되었던 날짜 정보를 전달한다.

쿠키를 위한 헤더 필드

쿠키는 유저 식별과 상태 관리에 사용되고 있는 기능이다.

  • 쿠키의 사양서

    1. 넷스케이프사에 의한 사양

      쿠키를 고안한 넷스케이프 커뮤니케이션스 사의 사양으로 현재 널리 보급되어 있는 쿠키 방식의 근원이다.

    2. RFC2109
    3. RFC2965

    4. RFC6265

      넷스케이프사에 의한 사양을 디 펙토 스탠다드로서 쿠키의 사양을 재정의한 것이다.

      넷스케이프사의 사양을 근간으로 확장한 것이다.

  • 쿠키를 위한 헤더 필드

    헤더 필드 명설명헤더 종별
    Set-Cookie상태 관리 개시를 위한 쿠키 정보Response
    Cookie서버에서 수신한 쿠키 정보Request

서버가 클라이언트에 대해서 상태 관리를 시작할 때 다양한 정보를 전달한다.

  1. Expires 속성

    브라우저가 쿠키를 송출할 수 있는 유효 기한을 지정할 수 있다.

  2. Path 속성

    쿠키를 송출하는 범위를 특정 디렉토리에 한정할 수 있다.

  3. Domain 속성

    쿠키의 domain 속성에 의해서 지정된 도메인 명은 후방 일치가 된다.

    명시적으로 여러 도메인에 대해서 쿠키를 송출하는 경우를 제외하고 domain 속성은 지정하지 않는 쪽이 안전하다.

  4. Secure 속성

    웹 페이지가 HTTPS에서 열렸을 때에만 쿠키 송출을 제한하기 위해서 지정한다.

    Set-Cookie: name=value; secure

    위의 경우 HTTPS일때만 쿠키를 반송한다.

    secure 속성을 생략한 경우에는 HTTP와 HTTPS 모두에서 쿠키를 반송한다.

  5. HttpOnly 속성

    XSS으로부터 쿠키의 도청을 막는 것이 목적이다.

    Set-Cookie: name=value; HttpOnly

    js의 [document.cookie]에서는 읽어 들일 수 없게 된다.

Cookie: status=enable

클라이언트가 HTTP의 상태 관리 지원을 원할 때 서버로부터 수신한 쿠키를 이후의 Request에 포함해서 전달한다.

그 이외의 헤더 필드

HTTP 헤더 필드는 독자적으로 확장할 수 있다.

X-frame-Option

X-Frame-Option: DENY

다른 웹 사이트의 프레임에서 표시를 제어하는 HTTP Response 헤더로, click jacking이라는 공격을 막는 것을 목적으로 하고 있다.

X-XSS-Protection

X-XSS-Protection: 1

XSS 대책으로서 브라우저의 XSS 보호 기능을 제어하는 HTTP Response 헤더이다.

DNT

개인 정보 수집을 거부하는 의사를 나타내는 HTTP Request 헤더이다.

P3P

웹 사이트 상의 프라이버시 정책에 사용하는 것으로, 프로그램이 읽을 수 있는 형태로 나타내기 위한 HTTP Response 헤더이다.

Book - 그림으로 배우는 Http & Network Basic
book Http Network HTTP 헤더
This post is licensed under CC BY 4.0 by the author.