03. HTTP 메시지

3.1 메시지의 흐름

HTTP 메시지

  • 정의: HTTP 애플리케이션 사이에서 주고받은 데이터 블록들

  • 구성: 1) 텍스트 메타 정보 + 2) 데이터(optional)

    • 텍스트 메타 정보: 메시지의 내용과 의미를 설명함

  • 방향: 인바운드, 아웃바운드, 업스트림, 다운스트림

3.1.1 인바운드: 서버 방향 송신

  • 인바운드: 사용자 에이전트 → 서버

  • 아웃바운드: 서버 → 사용자 에이전트

3.1.2 다운스트림: 메시지의 방향

  • 모든 메시지는 다운스트림으로 흐른다

  • 요청/응답 메시지 모두 다운스트림으로 흐른다

  • (업스트림) 발송자 → (다운스트림) 수신자

3.2 메시지의 각 부분

  • 시작줄 + 헤더 + 본문

  • 시작줄과 헤더는 CRLF로 구분되나, 그 자리에 개행 문자가 오기도 하고, 아무 것도 안 오기도 한다. 견고한 애플리케이션이라면 이런 모든 상황을 대처할 수 있어야 한다.

3.2.1 메시지 문법

  • 요청 메시지: 서버에 동작 요구

  • 응답 메시지: 요청의 결과를 클라이언트에게 돌려줌

    # 요청 메시지
GET /specials/saw-blade.gif HTTP/1.0
Host: www.joes-hardware.com

<메서드> <요청 URL> <버전>
<헤더>

<엔티티 본문>

# 응답 메시지
HTTP/1.0 200 OK
Content-Type: image/gif
Content-length: 8572

<버전> <상태 코드> <사유 구절>
<헤더>

<엔티티 본문>

요청 URL

  • 요청 대상 리소스의 완전한 URL 또는 URL의 경로 구성 요소

  • 불완전한 URL이더라도 서버는 생략된 호스트/포트가 자신을 가리키는 것으로 간주함

사유 구절

  • 상태 코드의 사람이 이해할 수 있는 버전

  • 특별한 규칙 없음

  • HTTP/1.0 200 NOT OK 와 HTTP/1.0 200 OK는 동등하게 성공을 의미하는 것으로 처리

엔티티 본문

  • 임의의 데이터 블록

  • 엔티티 블록을 포함하지 않는 메시지들은 그냥 CRLF로 끝남

3.2.2 시작줄

메서드

3.3 메서드

상태 코드

3.4 상태 코드

버전 번호

  • 요청, 응답 메시지에 모두 포함

  • 응답을 보낸 애플리케이션이 이해하는 가장 높은 HTTP 버전을 가리킴

  • HTTP 대화 상대의 능력과 메시지 형식에 대한 단서

  • HTTP 버전을 소수라고 생각하면 안 됨 (ex. HTTP/2.22는 HTTP/2.3보다 크다)

3.2.3 헤더

헤더 분류

  • 일반 헤더: 요청, 응답 양쪽에 모두 나타날 수 있음

  • 요청 헤더: 요청에 대한 부가 정보 제공

  • 응답 헤더: 응답에 대한 부가 정보 제공

  • Entity 헤더: 본문 크기와 콘텐츠 혹은 리소스 그 자체를 서술

  • 확장 헤더: 명세에 정의되지 않은 새로운 헤더

헤더를 여러 줄로 나누기

  • 긴 헤더 줄을 여러 줄로 쪼개서 더 읽기 좋게 만들 수 있다.

    # 두 헤더 줄은 같음
Server: Test Server
    Version 1.0
Server: Test Server Version 1.0

3.2.4 엔티티 본문

이미지, 비디오, HTML 문서, 소프트웨어 애플리케이션, 신용카드 트랜잭션, 전자우편 등 여러 종류의 디지털 데이터

3.2.5 버전 0.9 메시지

  • 요청: 메서드 + 요청 URL (ex. GET /specials/saw-blade.gif)

  • 응답: 엔티티

  • 버전 정보, 상태 코드, 사유 구절, 헤더 등이 없음

3.3 메서드

  • 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작을 요청 메시지에 전달

  • 한 단어로 되어 있음 (ex. GET, HEAD, POST)

  • 확장 메서드: 특정 서버가 추가로 구현한 HTTP 메서드

    메서드

    설명

    본문

    GET

    서버에서 어떤 문서를 가져온다.

    X

    HEAD

    서버에서 어떤 문서에 대해 헤더만 가져온다.

    X

    POST

    서버가 처리해야 할 데이터를 보낸다.

    O

    PUT

    서버에 요청 메시지의 본문을 저장한다.

    O

    TRACE

    메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다.

    X

    OPTIONS

    서버가 어떤 메서드를 수행할 수 있는지 확인한다.

    X

    DELETE

    서버에서 문서를 제거한다.

    X

  • 모든 서버가 모든 메서드를 구현하지는 않음

  • 메서드는 대부분 제한적으로 사용됨 (아무나 메서드를 사용할 수 없음)

3.3.1 안전한 메서드

  • HTTP 요청의 결과로 서버에 어떤 작용도 없는 것

  • 안전한 메서드가 서버에 작용을 유발하지 않는다는 보장은 없음

  • 안전한 메서드의 목적은 안전하지 않은 메서드가 사용될 때 사용자들에게 그 사실을 알려주는 것임

3.3.2 GET

  • 서버에게 리소스를 달라고 요청

  • HTTP/1.1은 서버가 GET을 구현할 것을 요구함

3.3.3 HEAD

  • GET처럼 행동하지만, 응답으로 헤더만 돌려주는 것

  • GET으로 얻는 헤더와 같은 헤더이고 엔티티 본문만 없는 것

  • 리소스가 삭제되거나 변경되었는지 검사

  • 리소스를 가져오지 않고 타입 등 정보를 알아냄

  • HTTP/1.1 준수를 위해서는 HEAD가 반드시 구현되어 있어야 함

3.3.4 PUT

  • 서버에 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만드는 것

  • 이미 해당 URL이 존재한다면 요청의 본문으로 교체하는 것

  • 많은 웹 서버가 PUT에 사용자 비밀번호를 이용해 로그인할 것을 요구함

3.3.5 POST

  • 서버에 입력 데이터를 전송 (ex. HTML 폼)

  • 데이터는 서버로 전송되고, 서버는 이를 모아서 필요로 하는 곳(게이트웨이 등)에 보냄

정리한 사람 주: PUT과 POST의 차이는 요청 URL

3.3.6 TRACE

  • 요청이 방화벽, 프락시, 게이트웨이 등 여러 애플리케이션을 통과할 수 있기 때문에, 클라이언트가 자신의 요청이 뮥적지 서버에 도달했을 때 어떻게 보이는지 TRACE를 통해 알 수 있다.

  • 요청은 엔티티 본문과 함께 보낼 수 없으며, 응답에는 서버가 받은 요청이 그대로 들어 있다.

  • loopback 진단

    • 마지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 응답

    • 클라이언트는 자신과 목적지 서버 사이에 있는 모든 HTTP 애플리케이션의 요청/응답 연쇄를 따라감

    • 프락시나 다른 애플리케이션이 요청에 어떤 영향을 미치는지 확인

  • 문제점: 중간 애플리케이션들이 TRACE 요청을 일관되게 다루지 않을 수 있음

3.3.7 OPTIONS

  • 리소스에 접근하지 않고 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어봄

3.3.8 DELETE

  • 서버에게 요청 URL의 리소스를 삭제할 것을 요청

  • HTTP 명세는 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용함. 따라서 삭제가 보장되지는 않는다.

3.3.9 확장 메서드

  • HTTP/1.1 명세에 정의되지 않은 메서드

  • ex. WebDav HTTP 확장: LOCK(리소스 잠금), MKCOL(문서 생성), COPY(복사), MOVE(이동)

  • "엄격하게 보내고 관대하게 받아들여라"

    • 프락시는 알려지지 않은 메서드가 담긴 메시지도 다운스트림 서버로 전달한다.

    • 해당 메서드가 end-to-end에 영향을 끼친다면, 501 Not Implemented 상태 코드로 응답한다.

3.4 상태 코드

대표적인 상태 코드

  • 200 OK: 성공 요청한 모든 데이터가 응답 본문에 들어 있다.

  • 401 Unauthorized: 사용자 이름과 비밀번호를 입력해야 한다.

  • 404 Not Found: 서버가 요청 URL에 해당하는 리소스를 찾지 못했다.

다섯 가지 분류

전체 범위

정의된 범위

분류

100-199

100-101

정보

200-299

200-206

성공

300-399

300-305

리다이렉션

400-499

400-415

클라이언트 에러

500-599

500-505

서버 에러

  • 인식할 수 없는 상태 코드를 받게 되면 그것이 포함되는 범위의 일부라고 가정해야 함

  • ex. 515는 다른 5XX 메시지들과 마찬가지로 서버 에러를 의미할 것

3.4.1 100-199: 정보성 상태 코드

  • HTTP/1.1에서 도입되었으며 감수할 만한 가치가 있는지 논란이 있음

상태 코드

사유 구절

의미

100

Continue

요청의 시작 부분 일부가 받아들여졌음

101

Switching Protocols

서버가 프로토콜을 클라이언트가 Upgrade 헤더에 나열한 것들 중 하나로 바꿈

100 Continue

  • 엔티티 본문을 서버가 받아들일 것인지 확인할 때 사용

  • 클라이언트는 100 Continue를 받고 나머지 요청을 계속 이어 보내야 함

  • 서버는 100 Continue를 보낸 이후 요청을 받아 응답해야 함

클라이언트와 100 Continue

  • 클라이언트는 첫 번째 요청의 헤더에 Expect: 100-continue를 보내야 함

  • 최적화: 서버가 다루거나 사용할 수 없는 큰 엔티티를 보내지 않기 위함

  • 클라이언트는 서버가 100-continue 응답을 내려주기를 마냥 기다리면 안 되고, 약간의 타임아웃 후에 그냥 엔티티를 보내야 함

  • 클라이언트는 예상하지 못한 100 Continue 응답에도 대비해야 함

서버와 100 Continue

  • 요청 헤더에 Expect: 100-continue가 있는 경우에만 100 Continue 응답을 주어야

  • 서버가 응답을 보내기 전 엔티티의 일부 혹은 전체를 받았다면, 100 Continue를 생략하고 해당 요청에 대한 응답만 보내면 됨

  • 100 Continue 요청을 받고 본문을 읽기 전 요청을 끝내기로 결정했을 때, 응답을 보내고 연결을 닫아 버리면 클라이언트는 응답을 받을 수 없게 됨 (cf. 4장 TCP 끊기와 리셋 에러)

프락시와 100 Continue

프락시가 100 Continue 요청을 받았을 때,

  • 다음 홉 서버가 HTTP/1.1을 따르거나, 어떤 버전을 따르는지 모른다면, 요청을 다음으로 전달

  • 다음 홉 서버가 HTTP/1.1 이전 버전이라면 417 Expecation Failed 에러로 응답

홉 (네트워크)

3.4.2 200-299: 성공 상태 코드

상태 코드

사유 구절

의미

200

OK

요청 정상, 엔티티 본문에 요청 리소스 포함

201

Created

생성 요청(ex.PUT)에 대해 리소스를 생성함 헤더에는 생성된 리소스의 구체적인 참조(Location 헤더) 포함 엔티티 본문에는 리소스를 참조할 수 있는 여러 URL 포함

202

Accepted

요청은 정상이나 서버는 어떤 동작도 수행하지 않음

(요청을 다른 프로세스에서 처리하거나, 서버가 다른 일을 하고 있기 때문) 엔티티 본문에 요청에 대한 상태와 가급적이면 언제 완료될 수 있는지에 대한 추정 포함해야 함

203

Non-Authoritative Information

엔티티 헤더에 들어있는 정보가 원래 서버가 아닌 중개자의 리소스 사본에서 옴 중개자로부 리소스 사본을 받았지만, 리소스 헤더가 서버와 일치하지 않는 경우

204

No Content

본문으로 보내줄 것은 없지만, 헤더와 상태줄이 의미 있는 경우 웹브라우저를 새 문서로 이동시키지 않고 갱신 (ex. 폼 리프레시)

205

Reset Conent

브라우저에게 현재 페이지에 있는 모든 HTML 폼 값을 비우라고 말함

206

Partial Content

부분 혹은 범위 요청이 성공 Content-Range, Date 헤더를 반드시 포함 Etag/Content-Location 헤더 중 하나도 반드시 포함

3.4.3 300-399: 리다이렉션 상태 코드

  • 리소스가 옮겨진 사실과 어디서 찾을 수 있는지(Location 헤더, optional)를 알려줌

  • 리다이렉트될 URL에 대한 링크와 설명을 포함하면 좋음

  • 클라이언트의 복사본이 여전히 최신인지, 원래 서버에 있는 리소스가 수정되었는지 검사

상태 코드

사유 구절

의미

300

Multiple Choices

동시에 여러 리소스를 가리키는 URL을 요청한 경우, 리소스 목록과 함께 반환함

301

Moved Permanently

요청한 URL이 Location 헤더에 있는 URL로 옮겨짐

302

Found

301과 같으나, 클라이언트는 Location 헤더의 URL을 임시로만 사용하고 이후에는 원래 URL을 사용해야 함

303

See Other

리소스를 Location 헤더에 있는 URL에서 가져와야 한다고 알려줌 POST에 대한 응답으로 클라이언트에게 리소스 위치를 알려줌

304

Not Modified

클라이언트가 조건부 요청을 했을 때 리소스가 최근에 수정되지 않았음을 알려줌 응답은 엔티티 본문을 포함하지 않음

305

Use Proxy

특정 리소스에 접근할 때 Location 헤더에 있는 프록시 URL을 통해야 함

306

(현재는 사용되지 않는 코드)

307

Temporary Redirect

301과 비슷하나, 클라이언트는 Location 헤더의 URL을 임시로만 사용하고 이후에는 원래 URL을 사용해야 함

302, 303, 307은 HTTP/1.0과 1.1에서 다름

서버가 POST 요청을 받은 뒤, 클라이언트가 리다이렉션 URL을 받고, GET 요청으로 리다이렉트를 따라가기를 기대하는 상황이라면

  • HTTP 1.0 클라이언트: 302 응답을 받고 GET 요청으로 Location 헤더에 있는 URL을 따라감

  • HTTP 1.1 클라이언트: 303 응답을 받고 GET 요청으로 Location 헤더에 있는 URL을 따라감 (307은 그대로 POST 메소드 사용할 때)

3.4.4 400-499: 클라이언트 에러 상태 코드

상태 코드

사유 구절

의미

400

Bad Request

클라이언트가 잘못된 요청을 보냄

401

Unauthorized

클라이언트에게 인증 요구

402

Payment Required

(현재 쓰이지 않음, 미래에 사용될 가능성)

403

Forbidden

요청이 서버에 의해 거부됨 엔티티 본문에 거부 이유를 설명할 수 있으나, 보통 거절의 이유를 숨기고 싶을 때 씀

404

Not Found

서버가 요청한 URL을 찾을 수 없음

405

Method Not Allowed

요청 URL에 대해 지하지 않는 메서드로 요청받음

406

Not Acceptable

주어진 URL에 대한 리소스 중 클라이언트가 요청한 규격에 맞는 것이 없음

407

Proxy Authentication Required

401과 같으나 프락시 서버를 위해 사용함

408

Request Timeout

클라이언트의 요청을 완수하기에 시간이 너무 많이 걸림

409

Conflict

요청이 충돌을 일으킬 염려가 있음 본문에 충돌에 대해 설명해야 함

ex. 서버에 있는 파일보다 오래된 파일을 PU으로 업로드할 때 버전 제어 충돌이 발생

410

Gone

404와 비슷하나 리소스를 가지고 있었다 제거된 경우

411

Length Required

요청에 Content-Length 헤더 요구

412

Precondition Failed

조건부 요청 중 하나가 실패

413

Request Entity Too Large

요청의 크기가 서버가 처리할 수 있는(or 처리하고자 하는) 한계를 넘음

414

Request URI Too Long

요청 URL 길이가 서버가 처리할 수 있는(or 처리하고자 하는) 한계를 넘음

415

Unsupported Media Type

서버가 지원하지 않는 유형의 엔티티 본문

416

Requested Range Not Satisfiable

요청한 리소스의 범위가 잘못됨

417

Expectation Failed

Expect 요청 더에 있는 내용을 서버가 만족시킬 수 없음

  • 클라이언트에서 올바른 요청을 보냈지만 서버에서 에러 발생

상태 코드

사유 구절

의미

500

Server Error

서버가 요청을 처리할 수 없음

501

Not Implemented

클라이언트가 서버가 구현하지 않은 메서드로 요청을 함

502

Bad Gateway

프락시나 게이트웨이 등 다음 링크로부터 부정적인 응답을 받음

503

Service Unavailabe

현재는 서버가 요청을 처리해줄 수 없지만 나중에는 가능함 Retry-After 헤더에 언제 가능한지를 포함하기도 함

504

Gateway Timeout

408과 비슷하지만 게이트웨이나 프록시가 보내는 응답

505

HTTP Version Not Supported

요청 프로토콜이 서버가 지원할 수 없는 버전임

3.5 헤더

  • <이름> <콜론(:)> (<공백>) <값> <CRLF>가 순서대로 나타나는 0개 이상의 헤더들

  • HTTP/1.1과 같은 몇몇 버전의 HTTP는 요청이나 응답에 특정 헤더가 포함되어야만 유효한 것으로 간주

3.5.1 일반 헤더

  • 클라이언트, 서버 모두 사용

  • 메시지에 대한 기본적 정보 제공

헤더

설명

Connection

현재의 전송이 완료된 후 네트워크 접속을 유지할지 말지를 제어

Date

메시지가 만들어진 날짜와 시간

MIME-Version

MIME 버전 (현재 1.0)

실질적으로는 해당 메시지가 MIME 형식임을 나타냄

Trailer

인코딩된 (chunked) 메시지의 끝 부분에 추가 헤더들의 목록

Transfer-Encoding

어떤 인코딩이 적용되었는지

Upgrade

클라이언트가 업그레이드하길 원하는 새 버전이나 프로토콜

Via

프락시, 게이트웨이 등 메시지가 거쳐온 중개자

매번 서버로부터 객체를 가져오는 대신 사본으로 캐시해주는 헤더

헤더

설명

Cache-Control

캐시 지시자 전달

cf. 쿠키/캐시 헤

Pragma

캐시 지시자 전달을 위한 또 다른 방법

  • 요청 메시지에 사용

  • 클라이언트의 선호나 능력

  • 서버가 더 나은 응답을 주는 데 활용

헤더

설명

Client-IP

클라이언트 IP

From

클라이언트 사용자의 메일 주소

Host

요청의 대상이 되는 서버의 호스트 명과 포트

Referer

요청 URI가 들어있었던 문서의 URL

UA-Color

클라이언트 기기의 디스플레이 색상 능력

UA-CPU

클라이언트 기기의 CPU

UA-OS

클라이언트 기기의 OS

UA-Pixels

클라이언트 기기의 디스플레이 픽셀

User-Agent

요청을 보낸 애플리케이션의 이름

Accept 관련 헤더

헤더

설명

Accept

서버가 보내도 되는 미디어 종류

Accept-Charset

서버가 보내도 되는 문자 집합

Accept-Encoding

서버가 보내도 되는 인코딩

Accept-Language

서버가 보내도 되는 언어

TE

서버가 보내도 되는 확장 전송 코딩

cf. TE (en)

transfer encodings(ko)

헤더

설명

Expect

요청에 필요한 서버의 행동

If-Match

문서의 엔티티 태그(ETag)가 주어진 엔티티 태그와 일치해야 함

cf. ETag

If-None-Match

문서의 엔티티 태그가 주어진 엔티티 태그와 일치하지 않아야 함

If-Modified-Since

주어진 날짜 이후에 리소스가 변경되었을 때만 요청 (변경되지 않았으면 제한)

If-Unmodified-Since

주어진 날짜 이후에 리소스가 변경되지 않았을 때만 요청 (변경되었으면 제한)

If-Range

문서의 범위에 대한 요청

Range

리소스에 대한 특정 범위를 요청

헤더

설명

Authorization

인증 자체에 대한 정보 (ex. username:pw)

Cookie

클라이언트가 서버에게 토큰 전달 보안 헤더는 아니지만 보안에 영향을 줌

Cookie2

클라이언트가 지원하는 쿠키의 버전

프락시 요청 헤더

헤더

설명

Max-Forwards

요청이 프락시나 게이트웨이로 전달될 수 있는 최대 횟수 TRACE 메서드와 함께 사용됨

cf. Max-Forwards, Proxy-Authorization, Referer, TE

Proxy-Authorization

Authorization과 같으나 프락시에서 인증할 때 쓰임

Proxy-Connection

Connection과 같으나 프락시에서 연결을 맺을 때 쓰임

  • 응답 메시지에 사용

헤더

설명

Age

응답이 얼마나 오래되었는지 초단위의 시간 보통 0이나 락시와 같은 중개자를 거쳐왔을 때는 있

Public

특정 리소스에 대해 지원하는 메서드 목록

Retry-After

리소스가 현재 사용 불가능할 때 언제 가능해지는지

Server

서버 애플리케이션의 이름과 버전

Title

HTML 문서 제목

Warning

자세한 경고 메시지

협상 헤더

  • 서버에 여러 가지 표현이 가능한 문서가 있을 때, 서버와 클라이언트가 그 중 어떤 표현을 택할 것인지 협상 지원

  • ex. 서버에 한국어, 영어로 번역된 HTML 문서가 있을 때

헤더

설명

Accept-Ranges

부분 요청을 할 때 서버가 자원에 대해 받아들일 수 있는 범위 단위의 형태 (ex. bytes)

Vary

응답에 영향을 줄 수 있어서 서버가 확인해 보아야 하는 헤더들의 목록

cf. Vary

헤더

설명

Proxy-Authenticate

프락시에서 클라이언트로 보낸 인증 요구의 목록

Set-Cookie

클라이언트에 토큰을 설정하기 위해 사용 보안 헤더는 아니지만 보안에 영향을 줌

Set-Cookie2

Set-Cookie와 비슷하되 RFC 2965로 정의됨

WWW-Authenticate

서버에서 클라이언트로 보낸 인증 요구의 목록

3.5.4 엔티티 헤더

  • 엔티티 본문에 대한 헤더

  • 요청과 응답 메시지 모두에 나타날 수 있음

헤더

설명

Allow

엔티티에 대해 수행될 수 있는 메서드 목록

Location

리소스의 (새로운) URL

콘텐츠 헤더

헤더

설명

Content-Base

본문의 상대 URL에 대한 기저 URL

Content-Encoding

본문에 적용된 인코딩

Content-Language

본문의 언어(자연어)

Content-Length

본문 길이

Content-Location

리소스 위치

Content-MD5

MD5 checksum

Content-Range

전체 리소스에서 해당 엔티티의 범위 (바이트)

Content-Type

본문의 종류

엔티티 캐싱 헤더

  • 언제 어떻게 캐시가 되어야 하는지, 캐시된 사본이 유효한지, 리소스가 유효하지 않게 되는 시점이 언제인지 등

헤더

설명

ETag

엔티티 태그

Expires

엔티티가 유효하지 않게 되는 일시

Last-Modified

엔티티가 최근 변경된 일시

cf. 확장 헤더

  • HTTP 명세에 없는 헤더

  • HTTP 애플리케이션은 확장 헤더의 의미를 몰라도 용인하고 전달할 수 있어야 함

Previous질문과 답변Next질문과 답변

Last updated

Was this helpful?