[HTTP 완벽 가이드] - HTTP 메시지

3장 HTTP 메시지

메시지의 흐름

메시지는 원 서버 방향을 인바운드로 하여 송신된다.

인바운드: 클라이언트에서 서버로
아웃바운드: 서버에서 클라이언트로

다운스트림으로 흐르는 메시지

메시지의 발송자는 수신자의 업스트림이다.
클라 → 서버 → 클라의 과정이 강물(다운스트림)처럼 흐름

메시지의 각 부분

메시지는 시작줄, 헤더 블록, 본문 이렇게 세 부분으로 나뉜다.

줄바꿈 문자열을 ‘CRLF’라고 쓰며 오래되거나 잘못 만들어진 HTTP 애플리케이션들 중엔 이를 전송하지 않는 것들도 있다.

메시지 문법

모든 HTTP 메시지는 요청 메시지나 응답 메시지로 분류된다.

// 요청 메시지 형식
<메서드> <요청 URL> <버전>
<헤더>

<엔터티 본문>

// 응답 메시지 형식
<버전> <상태 코드> <사유 구절>
<헤더>

<엔터티 본문>

요청 URL은 완전한 URL 혹은 URL의 경로 구성요소이다.

응답 메시지의 사유구절은 사람에게 읽히기 위한 목적으로 존재한다. ex) ‘OK’

헤더는 빈 줄(CRLF)로 끝나 헤더 목록의 끝과 엔터티 본문의 시작을 표시한다.

→ 마지막 CRLF를 빠뜨리는 것과 같이 규칙을 잘 지키지 않는 구현체와의 호환을 위해 클라이언트와 서버는 마지막 CRLF 없이 끝나는 메시지도 받아들일 수 있어야 한다.

HTTP의 구성요소에 대한 설명

메서드: GET, POST, PUT, DELETE외에 HEAD(서버에서 어떤 문서에 대한 헤더를 가져옴), TRACE(메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적), OPTIONS(서버가 어떤 메서드를 수행할 수 있는지 확인)

→ 이외의 서버에서 사용하는 메서드는 확장 메서드라고 불린다.(다른 서버가 그들만의 메서드를 구현한 경우)

상태코드: 클라이언트에게 무엇이 일어났는지 말해줌

전체범위	정의된 범위	분류
100-199	100-101	정보
200-299	200-206	성공
300-399	300-305	리다이렉션
400-499	400-415	클라이언트 에러
500-599	500-505	서버 에러

흔하게 보는 상태 코드

상태코드	사유 구절	의미
200	OK	성공! 요청한 모든 데이터는 응답 본문에 들어있다.
401	Unauthorized	사용자 이름과 비밀번호를 입력해야 한다.
404	Not Found	서버는 요청한 URL에 해당하는 리소스를 찾지 못했다.

버전번호: 버전번호는 HTTP/x.y 형식으로 요청과 응답을 메시지 양쪽 모두에 기술된다. 이는 때때로 혼란을 유발하는데, HTTP/1.1 이라는 응답을 받았을 때, 응답의 프로토콜 버전이 그 버전이 아닌 응답을 보낸 애플리케이션이 그 버전까지 이해할 수 있음을 의미하는 것이다.

버전 0.9 메시지

초기 응답 메시지는 오직 엔터티로만 되어 있어 상태 코드나 사유 구절도 없는 단순함 때문에 다양한 상황에 대응할 수 없었다.

메서드

모든 서버가 모든 메서드를 구현하지 않으며, 보통 GET이나 HEAD 메서드만을 구현하는 것으로 충분하다. 또한 메서드는 대부분 제한적으로 사용된다.(DELETE나 PUT 처럼 아무나 저장된 리소스를 삭제 및 변경하길 바라지 않는다.)

안전한 메서드

안전한 메서드란 HTTP 요청의 결과 서버에 어떤 작용도 없음을 의미한다.(GET, HEAD 처럼)

→ 이것의 목적은 서버에 어떤 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때, 사용자들에게 그 사실을 알려주는 HTTP 애플리케이션을 만들 수 있도록 하는 것에 있다.(안전하지 않은 요청 시, 서버에서 어떤일이 일어날 수 있음을 알려주는 경고 메시지를 띄우는 것)

HEAD

서버는 응답으로 헤더만으로 돌려주어 다음을 알 수 있다.

• 리소스를 가져오지 않고 그에 대해 무엇인가를 알아낼 수 있다.
• 응답의 상태 코드를 통해 엔터티가 존재하는지 확인할 수 있다.
• 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.

TRACE

목적지 서버에서 루프백 진단을 시작한다. → 주로 진단을 위해 사용

이 요청은 어떠한 엔터티 본문을 보낼 수 없고, 응답의 엔터티 본문에는 서버가 받은 요청이 그대로 들어있다.

OPTIONS

웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어본다.

→ 몇몇 서버는 특정 종류의 객체에 대해 특정 동작만을 지원한다.

응답의 결과로 헤더에 지원하는 HTTP 메서드 목록을 반환한다.

확장메서드

대표적인 예

LOCK(동시에 편집 못하도록 리소스 잠금기능), MKCOL(문서 생성), COPY(서버에 있는 리소스 복사), MOVE(리소스 옮김)

→ 확장 메서드에대해 관용적인 것이 좋다.

포스텔의 법칙(Postel's law)

견고함의 원칙 - 위키백과, 우리 모두의 백과사전

상태 코드

100-199: 정보성 상태 코드

상태코드	사유구절	의미
100	Continue	요청의 시작 부분 일부가 받아들여졌으며, 클라이언트는 나머지를 계속 이어서 보내야함을 의미한다. 이것을 보낸 후, 서버는 반드시 요청을 받아 응답해야 한다.
101	Switching Protocols	클라이언트가 Upgrade 헤더에 나열한 것 중 하나로 서버가 프로토콜을 바꾸었음을 의미한다.

클라이언트와 100 Continue

100-continue는 최적화를 위한 것이며 엔터티를 보내는 경우만 이 헤더를 보내야 한다.(서버를 혼동주지 않기 위해) 또한 헤더를 보내고 막연히 기다리기만해서는 안되고 일정시간 이후 클라이언트는 그냥 엔터티를 보내야한다.

서버와 100 Continue

100-continue 값이 담긴 Expect 헤더가 포함된 요청 수신 시, 100 Continue 응답 코드 혹은 에러 코드로 답해야하며, 이외의 다른 클라이언트에게 이를 보내선 안된다. 또한 응답을 보내기전 엔터티가 들어오기 시작했다면 다 받은 후에, 그 요청에 대한 최종 응답을 보내야한다. 만약 엔터티 본문을 읽기전, 요청을 끝내기로 결정했다면 서버는 그냥 응답을 보내고 연결을 닫아서는 안된다. → 클라이언트가 응답을 못받기 때문

프락시와 100 Continue

클라이언트로부터 100-continue 응답을 의도한 요청을 받은 프락시

다음 홉 서버가 HTTP/1.1 을 따르거나 어떤 버전을 따르는지 모른다 → Expect헤더 포함시켜서 요청을 다음으로 전달

다음 홉 서버가 1.1보다 이전 버전의 HTTP를 따른다는 것을 안다 → 417 Expecteation Failed 에러

프락시가 HTTP/1.0 이나 이전 버전을 따르는 클라이언트를 대신하여 Expect 헤더와 100-continue 값을 요청에 포함시키기로 결정했다면 그 응답을 클라이언트에게 전달 X → 클라이언트는 어떻게 해야할지 모르기 때문

리다이렉션 상태코드에서 원래 HTTP/1.0은 302 상태코드(클라이언트는 Location 헤더에 들어있는 리다이렉트 URL을 GET 요청으로 따라감)를 사용했다가 HTTP/1.1에서 303 상태코드를 사용하고, 혼란을 막기 위해 302대신 307을 사용하라고 한다.

헤더

서버가 무엇을 하는지 결정하기 위해 함께 사용

• 일반헤더: 클라, 서버 양쪽 모두 사용

  • ex) Date 헤더: 서버가 만들어진 일시를 지칭

    Date: Tue, 3 Oct 1974 02:16:00 GMT

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

  • 일반 캐시헤더: 로컬 복사본으로 캐시할 수 있도록 해주는 최초의 헤더(ex: Cache-Control)

• 요청 헤더

  • ex) Accept 헤더: 서버에게 클라이언트가 자신의 요청에 대응하는 미디어 타입을 받아들임

    Accept: */*

  • Accept 관련 헤더: 자신의 선호와 능력을 알려주어(무엇을 원하고 할 수 있는지) 서버와 클라이언트 양쪽 모두에게 유익한 헤더

  • 조건부 요청 헤더: 요청에 제약을 넣음(자신이 갖고 있는 사본과 다를 때만 전송해달라~)

  • 요청 보안 헤더: HTTP 자체적으로 요청을 하기 위한 간단한 인증요구/응답 체계를 갖고 있음(ex: Authorization, Cookie)

  • 프락시 요청 헤더: 프락시 기능을 돕기위한 헤더

• 응답 헤더: 클라이언트에게 정보를 제공하기 위한 자신만의 헤더
  • 협상 헤더: 여러가지 표현이 가능한 경우 HTTP/1.1은 서버와 클라이언트가 어떤 표현을 선택할 것인가에 대한 협상 지원
  • 응답 보안 헤더: 기본적인 인증요구 헤더(ex: Proxy-Authenticate, Set-Cookie(서버가 클라이언트를 인증할 수 있도록 클라이언트 측에 토큰 설정하기 위해 사용))

• 엔터티 헤더: 엔터티 본문에 대한 헤더 (본문에 들어있는 데이터의 타입 등등)
  • 양 타입의 메시지에 모두 나타날 수 있음(ex: Allow, Location)
  • 콘텐츠 헤더: 엔터티의 콘텐츠에 대한 구체적인 정보 제공(ex: Content- 로 시작하는것들)
  • 엔터티 캐싱 헤더: 엔터티 캐싱에 대한 정보로 리소스에 대한 캐시 사본이 아직 유효한지 정보와 캐시된 리소스가 더 이상 유효하지 않게 되는 시점을 더 잘 추정하기 위한 단서(ex: Expires, Last-Modified)

• 확장 헤더: 아직 승인된 HTTP 명세에는 추가되지 않은 비표준 헤더