[HTTP 완벽 가이드] 03 HTTP 메시지_의사소통이 필요할 땐

HTTP 완벽 가이드

중요하다고 생각한 점

메시지 구성요소

3.2.2 시작줄

- 요청줄
- 응답줄
- 메서드
- 상태 코드
- 사유 구절
- 버전 번호

3.2.3 헤더

- 헤더 분류
- 일반 헤더
- 요청 헤더
- 응답 헤더
- Entity 헤더
- 확장 헤더

3.2.4 엔터티 본문

<요청 메시지의 형식>

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

<엔터티 본문>

e.g.
GET /specials/saw-blade.gif HTTP/1.0
Host: www.joes-hardware.com

<응답 메시지의 형식>

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

<엔터티 본문>

e.g.
HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 8572

상태 코드의 종류

전체 범위	정의된 범위	분류
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에 해당하는 리소스를 찾지 못했다.

안전한 메서드(Safe Method)

안전한 메서드가 서버에 작용을 유발하지 않는다는 보장은 없다(사실 그건 웹 개발자에게 달렸다). 안전한 메서드의 목적은, 서버에 어떤 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자들에게 그 사실을 알려주는 HTTP 애플리케이션을 만들 수 있도록 하는 것에 있다. (61쪽)

헤더

생각했던 것보다 헤더의 종류가 굉장히 많아, 이전에 프로젝트에서 눈에 익었던 것들을 위주로 정리해 본다.

<엔터티 헤더>

: 엔터티 헤더는 엔터티 본문에 들어있는 데이터의 타입이 무엇인지 말해줄 수 있다.

• Content-Type: [엔터티 헤더] 이 본문이 어떤 종류의 객체인지
  주로 application/json을 쓰지만, 아래 코드처럼 multipart/form-data가 될 수도 있는데, 이는 본문이 이미지일 경우이다.

• Content-Length: [엔터티 헤더] 본문의 길이나 크기

<요청 헤더>

: 서버에게 클라이언트가 받고자 하는 데이터 타입이 무엇인지와 같은 부가 정보를 제공한다.

• Host: [요청 헤더] 요청의 대상이 되는 서버의 호스트 명과 포트를 준다.

• User-Agent: [요청 헤더] 요청을 보낸 애플리케이션의 이름을 서버에게 말해준다.

<Accept 관련 헤더>

: 클라이언트는 Accept 관련 헤더들을 이용해 서버에게 자신의 선호와 능력을 알려줄 수 있다. 즉 클라이언트가 무엇을 원하고 무엇을 할 수 있는지, 그리고 무엇보다도 원치 않는 것은 무엇인지 알려줄 수 있다. 서버는 그 후 이 추가 정보를 활용해서 무엇을 보낼 것인가에 대해 더 똑똑한 결정을 내릴 수 있다. Accept 관련 헤더들은 서버와 클라이언트 양쪽 모두에게 유익하다. 클라이언트는 그들이 원하는 것을 얻을 수 있으며, 서버는 클라이언트가 사용할 수도 없는 것을 전송하는 데 시간과 대역폭을 낭비하지 않을 수 있다. (79쪽)

• Accept: [Accept 관련 헤더] 서버에게 서버가 보내도 되는 미디어 종류를 말해준다.

• Accept-Encoding: [Accept 관련 헤더] 서버에게 서버가 보내도 되는 인코딩을 말해준다.

<일반 헤더>

: 메시지에 대한 아주 기본적인 정보.

• Connection: [일반 헤더] 클라이언트와 서버가 요청/응답 연결에 대한 옵션을 정할 수 있게 해준다.

<요청 보안 헤더>

: HTTP는 자체적으로 요청을 위한 간단한 인증요구/응답 체계를 갖고 있다. 그것은 요청하는 클라이언트가 어느 정도의 리소스에 접근하기 전에 자신을 인증하게 함으로써 트랜잭션을 약간 더 안전하게 만들고자 한다. (80쪽)

• Authorization: [요청 보안 헤더] 클라이언트가 서버에게 제공하는 인증 그 자체에 대한 정보를 담고 있다.

의문이 든 점

CRLF?

HTTP 메시지 내 빈 줄로 끝날 경우 CRLF라 하는데, 분명히 익숙한 이 단어...

warning: CRLF will be replaced by LF in some/file.file.
The file will have its original line endings in your working directory.

첫 프로젝트 때 열심히 작업하고 겨우겨우 git commit했을 때 왕왕 마주했던 오류!

다행히 한 번 설정하면 그 다음부터 발생하지 않는 오류지만,
처음에는 나 잘못한 거 없는데 왜, 뭐 때문에?라는 생각이 마구 들었었다.
(실제로 내가 잘못한 거 없음)

아무튼 간단히 얘기하자면,

CRLF=Carriage Return & Line Feed를 의미하는데,

타자기 시절 줄바꿈을 할 때 쓰는 Carriage에서 착안하여,
컴퓨터에서의 키보드 줄바꿈을 의미하는 용어이다,
Line Feed는 또한 해당 줄이 끝났음을 의미하는 개행 문자이다.

그래서 위에서 발생한 CRLF가 LF로 대체될 것이다라는 오류는
운영 체제별로 개행 문자를 처리하는 방식이 달라서이기 때문인데,
협업 시 mac, window 간의 파일 공유가 있을 때
처리하는 방식이 다르게 때문에 발생하는 오류이다.

자세한 에러 사항과 해결 방법은 여기

사유 구절

사유 구절은 오로지 사람에게 읽히기 위한 목적으로만 존재하는 것이다. 예를 들어 'HTTP/1.0 200 NOT OK'와 'HTTP/1.0 200 OK'는 사유 구절이 서로 전혀 달라 보임에도 불구하고 동등하게 성공을 의미하는 것으로 처리되어야 한다. (53쪽)

이럴 거면 굳이 사유 구절을 왜 넣을까 하는 의문이 들었지만,
단순히 사유 구절은 주석의 역할을 하는 것 뿐이다라고 해석하면 될 것 같다.

UA- 헤더

요청 헤더들 중에 클라이언트 기기 디스플레이의 색상 능력(UA-Color), CPU의 종류나 제조사(UA-CPU), 동작 중인 운영체제의 이름과 버전(UA-OS) 등을 알려주는 것들이 있다. 처음에 이를 보고는 '보안 상의 문제는 없나?', '잘만 활용하면 사용자별 커스텀된 페이지를 보여줄 수도 있겠다.'라는 생각이 들었는데, 책에서는 이러한 설명을 덧붙였다.

몇몇 클라이언트에서 구현되어 있기는 하지만, UA-헤더는 해로운 것일 수도 있다. 콘텐츠(특히 HTML)는 특정 클라이언트 설정에 맞추어져서는 안 된다. (79쪽)

기회가 된다면 직접 헤더 설정을 해서 요청을 보낸 뒤, 맞는 정보가 가는지 테스트해보고 싶다.

문제

1. HTTP 메시지는 단순한, (                          )이다.
2. 다음 중 버전이 더 큰 것(최신)은?
   HTTP/2.3   HTTP/2.11
3. 다음 중 메서드에 관한 설명 중 옳은 것은?
   1) 안전한 메서드는 서버에 작용을 유발하지 않는다.
   2) POST는 서버에 있는 리소스에 데이터를 입력하기 위해 사용하고, PUT은 서버에 데이터를 보내기 위해 사용한다.
   3) TRACE 요청은 어떠한 엔터티 본문도 보낼 수 없다.
   4) OPTIONS 메서드는 주로 진단을 위해 사용된다.
   5) DELETE 메서드는 삭제가 수행되는 것을 보장한다.

<답>

1. 데이터의 구조화된 블록
2. HTTP/2.11, 버전 번호는 분수로 다루어지지 않고 각각 분리된 숫자로 다루어지기 때문
3-1) 안전한 메서드가 서버에 작용을 유발하지 않는다는 보장은 없다(사실 그건 웹 개발자에게 달렸다). (61쪽)
3-2) PUT은 서버에 있는 리소스에 데이터를 입력하기 위해 사용하고, POST는 서버에 데이터를 보내기 위해 사용한다. (63쪽)
3-3) TRACE 요청은 어떠한 엔터티 본문도 보낼 수 없다. TRACE 응답의 엔터티 본문에는 서버가 받은 요청이 그대로 들어있다. (65쪽)
3-4) OPTIONS 메서드는 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어본다. 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있다. (65쪽)
3-5) (DELETE 메서드는) 서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청한다. 그러나 클라이언트는 삭제가 수행되는 것을 보장하지 못한다. 왜냐하면 HTTP 명세는 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용하기 때문이다. (66쪽)

느낀 점

HTTP 명세가 잘 되어 있음에도 불구하고, 실제로 쓰이는 것은 너무 적지 않나라는 생각이 들었다.
보통은 클라이언트 에러/서버 에러가 났을 때 만나는 건
404(Not Found), 502(Bad Gateway)인데, 이 외의 에러가 나기는 하는
것일까하는 생각이 들고, 오히려 안 난 것이 다행인 것인지라는 생각도 들었다.

이렇게 퉁쳐서 보내는 경우가 대부분일 듯.

상태 코드를 세분화하는 것이 유지보수나 문제해결에 있어서 가장 적절한 것을 알고 있는데, 그걸 실제로 적용하는 경우가 많은지 궁금하다.

한 줄 요약

무궁무진한 상태 코드와 헤더의 세계!