HTTP message

1. 인바운드 - 아웃바운드, 다운스트림

서버를 기준으로 유입되는 트래픽 / 요청등을 인바운드, 그에 대한 응답이나 직접 클라이언트에게 응답을 보내는 경우를 아웃바운드라고 한다. 즉, 서버를 기준으로 들어오는 것은 인바운드, 나가는 것은 아웃바운드라고 생각하면 된다.

HTTP 메시지는 항상 물처럼 흐르고 역류 하지 않는다. 메시지의 발신자는 수신자의 업스트림이 되며, 메시지는 다운스트림으로 보내진다. 서버인지 클라이언트인지에 상관없이 업스트림과 다운스트림은 상황에 따라 바뀌게 된다.

client(업스트림) -> server(다운스트림)
client(다운스트림) <- server(업스트림)

2. Message

1. 메시지의 세 부분

• 메시지는 보통 [시작줄 - 헤더 - 본문]의 구조로 되어있다.

2. 메시지의 구조

• Reqeust의 경우

<Method> <URL> <HTTP version> ] 시작줄
<Header>                      ] 헤더

<Content>                     ] 본문

• Response의 경우

<HTTP version> <Status code> <Reason phase> ] 시작줄
<Header>                                    ] 헤더

<Content>                                   ] 본문

• Method: 사용된 HTTP method의 종류.
• URL: Request를 요청받는 측의 URL.
• HTTP version: HTTP 버전을 나타내며, 어떤 어플리케이션이 지원하는 가능 높은 HTTP 버전을 나타낸다.
• Status code: 어떤 request의 실행결과를 숫자로 보여준다.
• Reason phase: 사람이 알아볼 수 있게, status code와 함께 리턴되는 간단한 메시지.
• 본문: 있을수도 있고, 없을수도 있는 화물. HTTP가 이것을 운송하도록 설계되었다. 이미지, 비디오, 텍스트, 소프트웨어 어플리케이션 등 많은 것을 포함할 수 있다.

기억해야 할 점은 request, response 메시지의 본문은 있을수도 있고 없을수도 있다는 것이며, 메시지 본문의 유무와 상관없이 Header의 끝은 반드시 CRLF로 마무리 되어야 한다는 것이다.

3. Header

1. Header의 특징

• 0개 혹은 그 이상의 헤더가 위치할 수 있다.
• 각각 CRLF로 구분한다.
• key-value의 구조를 가진다. Content-Type: text/html

2. Header의 종류

A. 일반 헤더

• 일반 헤더는 클라이언트와 서버 양쪽 모두가 사용한다. 일반적으로, 메시지에 대한 아주 기본적인 정보를 제공하는 경우 사용하게 된다.

B. 일반 캐시 헤더

C. 요청 헤더(Request Header)

• 요청(Request) 메시지에서만 의미를 갖는 헤더로, 보통 클라이언트 측에서 자동으로 작성되어 보내지는 경우가 많다. 물론, 조작될 가능성도 있으니 주의해야 한다.

예시
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

• Accept 관련 헤더는 주로 클라이언트에서 사용되는 미디어의 종류에 대해서 보내게 된다. 각 헤더는 콤마로 구분 가능하며, 와일드카드 역시 동작한다.

예시
Accept: text/html

Accept: image/*

Accept: text/html, application/xhtml+xml

• 조건부 요청 헤더는 클라이언트가 요청에 대해 몇몇 제약을 넣고자 할 때 사용한다. 예를들어 클라이언트가 이미 어떤 문서의 사본을 가지고 있는 상태라면, 클라이언트는 서버에게 이 문서의 사본과 원본이 다를때만 전송해 달라고 요청 할 수 있다.

• 보안 헤더는 간단한 인증요구/응답을 위해 사용된다. 보안 헤더의 종류는 아니지만, Cookie역시 이러한 역할을 한다고 볼 수 있다.

• proxy 요청 헤더

D. 응답 헤더(Response Header)

• 응답(Response) 헤더는 클라이언트에게 부가 정보를 제공한다.

• 협상 헤더

• 응답 보안 헤더

E. 엔터티 헤더

• HTTP message의 엔터티(본문)에 대해 설명하는 헤더들로, 요청과 응답 양쪽 모두에서 사용할 수 있다.

• 정보 헤더

• 콘텐츠 헤더

• 엔터티 캐싱 헤더

4. Method

Method는 클라이언트가 서버측에 특정한 동작을 요청하는데 쓰이는 것으로, 서버마다 구현되어있는 method는 각각 다를 수 있지만, 개발자는 최대한 method의 목적에 맞는 기능을 구현해야 한다.

A. 안전한 method

HTTP에는 안전한 method의 집합이 있다. 안전한 method란 다음과 같은 method를 의미한다.

• HTTP 요청으로 인해 서버 혹은 DB에 아무런 작용이 일어나지 않는 method.
• 작용이란 DB에 새로운 값이 입력, 수정, 삭제되거나 신용카드로 대금이 청구되는 등의 동작을 이야기 한다.
• 안전한 method에는 GET, HEAD등이 있다.

B. Method의 종류

• HEAD method를 사용하게 되면, 리소스를 직접 가져오지 않고 리소스의 존재 여부, 타입 등을 알아낼 수 있다. HTTP/1.1 스펙을 준수하기 위해서는 HEAD가 반드시 구현되어 있어야 하고, HEAD를 통해 반환되는 header와 GET을 통해 반환되는 header는 반드시 일치해야 한다.

• PUT과 POST method가 하는 일은 조금 다른데, 실제로 api서버를 개발할 때 POST는 새로 생성 PUT은 변경 혹은 수정에 사용했었던 기억이 있다.

• PATCH라는 method는 책에 소개되어있지는 않지만 예전에 api서버를 개발할 때의 기억이 있어 추가해 보았다. PATCH는 PUT과 비슷한 역할을 하지만, PUT은 문서 전체를 변경하는 대신 PATCH는 일부분만 변경하기 때문에 update기능을 구현하는데에 의미적으로 조금 더 적합하지 않나 하는 생각이 든다.

5. Status code, Reason phase

Status code와 reason phase는 response message에 포함되어 반환되는 값으로, 클라이언트의 요청에 대해 서버가 처리한 결과이다. Status code는 보통 세자리의 숫자기 때문에 코드상에서 에러 처리등의 용도로 사용한다. Reason phase는 status에 대해서 사람이 좀 더 알아보기 쉬운 짧은 readable text 형태이기 때문에 status code를 좀 더 쉽게 이해하도록 도와준다.

Status code는 상태에 따라 반환하는 code와 범위를 미리 지정해 놓았다 (RFC 7231).

미리 정의된 code를 제외하고 status code를 새로 기술할 때는 두 가지 규칙을 따라야 한다.

• 상태코드의 약속된 범위내에 포함되는 에러라고 간주할 수 있어야 한다. 즉 성공을 나타내는 200번대 status code에 서버 에러에 대한 code를 정의하면 안된다.
• 미리 정의된 status code를 임의로 변경하지 않는다.

A. 200번대 status code

200번대의 status code는 요청에 대해 성공했음을 알려주는 code로 구성되어 있다.

B. 300번대 status code

300번대의 status code는 요청에 대한 리소스가 옮겨지거나 다른 위치를 참조해야할 때 사용되며, 이는 브라우자가 사용자를 귀찮게 하지 않고 알아서 새 위치로 이동할 수 있게 해준다.

C. 400번대 status code

400번대의 status code는 클라이언트의 에러를 나타내며, 404와 같은 몇몇 에러를 제외하면 브라우저에 의해 처리된다. 400번대의 status code는 종류가 많기때문에, 주로 사용되는 것에 대해서만 설명하고자 한다. 나머지 status code에 대해서는 이곳을 참고하면 좋을 것 같다.

D. 500번대 status code

500번대의 status code는 서버의 에러를 나타낸다.

6. Conclusion

HTTP 완벽 가이드의 3장을 가볍게 정리해 보았다. 저번과 마찬가지로 대충 알고 있던 부분을 채울수 있어서 좋았고, 몰랐던 부분을 알수 있게되어 더 느낌이 좋았다. 다만 이번의 글은 “공부했다!”라는 느낌 보다는 단순한 정보의 나열처럼 보이는 것이 조금은 아쉽다.

특히 header부분을 공부하고 나서보니 개발자 도구의 network탭이 새롭게 보이는 효과를 보았다. 생각보다 header가 큰 역할을 하고 있으며, 적절히 사용하면 앞으로의 프로젝트에도 도움이 될 것이라 생각한다.

참고

• HTTP 상태 코드
• 도서 HTTP 완벽 가이드