HTTP 메시지

반응형
반응형

이번 파트에서는 HTTP 메시지를 어떻게 작성하는지 알아본다고 한다.
메소드는 어떤것이 있으며...
상태코드는 어떤것들이 있으며... 근데 솔직히 너무 많은데 다 작성할 수 있을지 걱정 된다.
책에서는 이번 장을 읽고 나면 나만의 HTTP 애플리케이션을 만들기 위해 필요한 부분들을 알게 될거라 한다

메시지가 어떻게 흘러가는가
HTTP 메시지의 세 부분(시작줄,헤더,개체 본문)|
요청과 응답 메시지의 차이
요청 메시지가 지원하는 여러 기능(메서드)들
응답 메시지가 반환하는 여러 상태 코드들
여러 HTTP 헤더들은 무슨 일을 하는가

메시지의 흐름

aws를 하다보면 인바운드, 아웃바운드 같은 용어가 등장하는데 뭔지 몰라서 aws에서 하라는데로 했던걸로 기억한다.
이들은 메시지의 방향을 뜻한다고 한다. 이번 기회에 재대로 학습해 보자.

인 바운드, 아웃 바운드

여기서 인 바운드는 정방향을 의미하는 것 같다.

client에서 가까울 수록 사용자와 가깝고
server와 가까울수록 서버와 가까운것 같다.
생각해보자. 내가 웹 서버스를 하나 론칭한다고 가정하자.
론칭을 하기 위해서는 서버가 필요하다. 왜냐하면 웹 서비스 같은 경우 거의 모든 사람들이 이용을 할 수 있어야 하기 때문이다.
그러면 서버가 필요한데, 직접 서버를 구축할 수 도 있지만... 
aws처럼 클라우드 서비스의 힘을 빌려 서버를 구축할 수 도 있다.
그러면 인 바운드가 클라이언트에서 서버이니까 서버를 구동을 하기위해 어떠한 정보를 알아야 하는데 서버는 그 정보는 모르는 상태, 하지만 클라이언트는 그것을 아는 상태하면 클라이언트는 서버쪽으로 그 정보를 전달을 해야한다.
이것이 내가 생각하는 인 바운드다.
그러면 아웃 바운드는 반대 겠지?
서버는 아는데 클라이언트는 모르는 상태, 그런데 클라이언트도 그 정보를 알아야 하는 상황이라면 아웃 바운드가 적용이 될거라 생각한다.

놀랍게도 이 용어는 마케팅 용어로 사용이 되고 있다고 한다.
내가 마케팅을 공부를 하는게 아니기 때문에 간단하게 소개하고 넘어가자면,
아웃 바운드는 기업이 직접 소비자에게 마케팅을 하는 행위이고,
인 바운드는 소비자가 직접 마케터가 되어서 마케팅을 하는거라고 한다.

내가 굳이 이것을 말하는 이유는 의미는 달라도 뿌리는 같을거라 생각을 했고,
어쩌면 이것을 조금더 쉽게 이해할지도 모른다고 생각했기 때문이다.
그러면 마케팅 관점으로 생각을 해보자면,
아웃 바운드는 서버가 클라이언트로 전달이 되는 거라면,
인 바운드는 클라이언트 자체가 서버가 되는 느낌인것 같다.
물론 틀린 말일 수도 있다. 하지만 지금 중요한건 완벽하게 설명하는 것보다 이것이 어떤 느낌의 용어인지 아는게 중요하다고 생각이 든다.
그러니까 아웃 바운드는 서버로 인 바운드는 클라이언트로 전달되는 거라 이해 하는것이 맞는것 같다.

또, 다운스트림과 업스트림이라는 용어가 있는데 이건 HTTP메시지가 흐름을 나타내는 용어라구 하고
물이 위에서 아래로 흐르듯이 모든 메시지는 다운 스트림으로 흐른다고 한다.
그 반대는 업스트림이라고 한다는데 메시지는 그런식으로 흐르지 않는다.

그거 그렇게 하는거 아닌데

메시지의 각 부분

HTTP는 총 세 부분으로 구분이 되어집니다.
시작줄, 헤더, 본문 이렇게 나눠 집니다.

시작줄은 어떤 메시지인지 서술하며,
헤더 블록은 속성을
본문은 있을 수도 있고 없을 수 도 있다고 합니다.
이는 추후에 학습이 되어질 것 같습니다.
시작줄과 헤더는 줄 단위로 구분되어지는 아스키 문자열이라고 합니다.
각 줄은 캐리지 리턴(ASCII 13) 개행 문자(ASCII 10)으로 구성되어있다고 합니다.
이러한 줄 바꿈을 CRLF라고도 한다고 합니다.

본문 같은 경우, 시작줄과 헤더와 달리 선택적인 요소입니다.
즉, 이진 데이터가 들어올 수도, 일반적인 텍스트가 들어올 수도 
아니면 아무것도 작성이 되지 않아도 된다고 합니다.

다음은 캐리지 리턴에 관한 위키백과 글입니다.

 

캐리지 리턴 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전.

ko.wikipedia.org

읽어보니 캐리지 리턴을 줄여서 CR이라고 하는 것으로 봐서 
개행 문자는 LF으로 유추할 수 있을것 같습니다.

 

새줄 문자 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. "Hello"와 "world" 단어 사이에 추가된 새 줄 새줄 문자(newline)는 텍스트의 한 줄이 끝남을 표시하는 문자 또는 문자열이다. 개행 문자, 줄바꿈 문자(line break), EOL(end-

ko.wikipedia.org

LF는 라인 피드의 약자인것 같다.

메시지 문법

저번에 URL문법을 공부했던것 처럼 메시지에도 문법이 존재한다.
요청 메시지같은 경우, 웹 서버에 어떤 동작을 요구하는 것을 말하고,
응답 메시지는 요청의 결과를 클라이언트에게 돌려주는 역할을 한다.

요청 메시지는 다음 처럼 작성되어진다고 한다.

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

<엔티티 본문>

응답 메시지는 다음과 같다.

<메서드> <상태 코드> <사유 구절>
<헤더>

<엔티티 본문>

확인 결과 시작 줄에서만 문법이 조금 다르다는 것을 알 수 있다. 
이것들이 어떤 의미를 가지는지 알아보자.

  메서드 클라이언트 측에서 서버가 리소스에게 수행해주길 바라는 동작
  요청 URL 요청 대상이 되는 리소스를 지칭하는 완전한 URL 혹은 URL의 구성 요소
  버전 이 메시지에서 사용 중인 HTTP의 버전
  상태 코드 요청 중에 무엇이 일어났는지 설명하는 세 자리 숫자
  사유 구절 숫자로된 상태 코드의 의미로 사람이 이해 할 수 있게 설명해주는 짧은 문구
  헤더들 이름, 콜론(:), 선택적인 공백, 값, CRLF가 순서대로 나타낸다.
  엔티티 본문 임의의 데이터 블록을 포함

위에서 시작줄, 헤더, 본문으로 구분지어졌다고 했는데
시작줄에 대해 조금더 자세히 알아봅시다.

시작줄

 요청줄  (요청 메시지)
          - 서버에게 리소스에 대해 무언가를 해달라고 부탁한다.
          - 서버에서 어떤 동작이 일어나는지 설명해주는 메서드와 그 동작에 대한 대상을 지정하는 요청 URL이 포함된다.

 응답줄 (응답 메시지)
         - 수행 결과에 대한 상태 정보와 결과 데이터를 클라이언트에게 돌려준다.

 메서드
         - 서버에게 무엇을 해야 하는지 말해준다.

헤더

  시작줄 다음에 오며, 0개이상을 나타낸다.
  즉, 한개도 없을 수 도 있다는 뜻이다.

   일반 헤더 요청과 응답 양쪽에 모두 나타낼 수 있다.
   요청 헤더 요청에 대한 부가 정보를 제공
   응답 헤더 응답에 대한 부가 정보를 제공
   Entity 헤더 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 서술
   확장 헤더 명세에 정의 되지 않은 세로운 헤더

헤더를 여러 줄로 나누기

헤더가 너무 길며 읽기 불편하기 때문에 최소 하나의 스페이스 혹은 탭문자가 온다.

  엔티티 본문

마지막 본문... 책에서는 HTTP계의 화물이라고 한다.
그렇다는건 수 많은 데이터를 본문에 실어서 옮긴다는 그런 말인 건가...

메서드

http의 메서드는 1.1이전과 이후로 나눠지는데..
지금 우리가 학습하고 있는 부분은 1.1부분이다.

사실 자신의 리소스에 대해 GET과 HEAD로만 충분하다고 한다고 한다.

안전한 메서드

메서드가 안전하다는 말은 HTTP 요청 결과로 서버에 어떤 작용이 없다는 것이라고 합니다.
HTTP메서드에서는 GET과 HEAD,OPTION이 존재합니다.
안전한 메서드의 목적은, 서버에 어떤 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자들에게 그 사실을 
알려주는 HTTP 애플리케이션을 만들 수 있도록 하는 것에 있다고 합니다.

일반적으로 안전한 메서드는 서버에 영향을 주지는 않지만, 종종 서버에 문제가 될 수도 있다고 합니다.(개발을 잘못하면)
지금 이것을 읽은뒤, 드는 생각은 재대로 개발만한다면 안전한 메서드로 문제될 일은 전혀 없을 거라 생각이 들고...
회사에서 어떤 문제가 발생했는지에 대해 생각해보면, 대부분 POST,PUT이었던걸로 기억하구
GET은 문제가 되었던적이 없던것 같습니다. 
자 그럼 지금부터 자세하게 알아봅시다. 

GET

이것은 데이터를 가져올때 사용되는 메서드로 가장 많이 사용되어진다.
위에서 확인했듯이 이는 안전한 메서드의 하나입니다.
GET <요청 URL> HTTP/1.1 이런식으로 요청하구
HTTP1.1 200 ok 응답 처리 됩니다.
추후에 상태 코드에 대해 학습할 예정이지만 200번대는 성공 상태를 뜻합니다.

 HEAD

정확히 GET 처럼 행동하지만 다른 점이 하나 존재한다면,
그건 본문을 가져오지 않는다고 합니다. 본문을 가져오지 않는다는 이야기는
웹 상에 아무것도 보이지 않은 상태라 생각한다.
그러니까 html도 없는 상태라고 해야 되나...
아무튼 이것을 사용 하는 이유는 3가지로 작성이 되어있습니다.
  - 리소스를 가져오지 않고도 그에 대해 무엇인가를 알 수 있다.
  - 응답의 상태 코드를 통해, 개체가 존재하는지 확인 할 수 있습니다.
  - 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있습니다.

솔직히 잘 모르겠다. 스프링을 하면서 HEAD 메서드를 사용하는 일이 없다보니... 그런것 같기두 하구

  @RequestMapping(value = "/api", method = RequestMethod.HEAD)
  public String head() {
    return "hello";
  }

억지로 하려면 이 방법밖에 없는것 같습니다.
아무튼 이것의 리턴을 Hello로 두고 테스트 코드를 작성해보겠습니다.

  @Test
  void head_() throws Exception {
    mockMvc.perform(head("/api"))
            .andExpect(status().isOk())
            .andDo(print());
  }

결과는 놀랍게도

body가 나오지 않는다는것을 알 수 있습니다.
코드는 유지한채 메서드만 get으로 수정해보겠습니다.

 body가 들어왔다.
그러면 head를 사용하는것이 좋은지에 대해 고민해보자.
리턴값(본문)이 존재 하지 않기 때문에 빠르게 리소스의 상태를 체크 할 수 있을 것 같다.
아무래도 본문이 없는게 더 가볍지 않을까?

PUT

GET이 가져오는 역할을 담당한다면, PUT은 문서를 작성하는 역할을 한다.
또 특징이 있는데 URL(리소스)가 이미 존재한다면 본문을 사용해서 교체한다고 한다.
결국, 기존의 리소스는 해치지 않고 본문을 가지고 수정되어지는 것 같다.

대부분 수정할때 사용되어지는데 교체라는 특성때문이라 생각이 든다.
여기서 리소스가 이미 존재한다는 뜻은 404가 아니라는 뜻이 된다.

 POST

어떻게 보면 PUT과 같은 양상을 띄는 것 같지만 전혀 다릅니다.
PUT은 기존에 존재하는 URL(리소스)에 입력하는 것이라면,
POST는 특정 URL(리소스)에 데이터를 전송하는 것을 의미합니다.
즉, 폼데이터를 만들어서 그 데이터를 URL에 전송한다.
대표적으로 회원가입이 있다.
회원가입을 할때를 생각해보면, 회원가입으로 하는 링크, 확인 링크 이렇게 나눠져 있을 것이다.
그러면 리소스는 이미 존재한다는 것을 뜻하며, 
회원가입을 할때마다 빈 폼이 나온다. 왜냐하면 회원가입 완료시 데이터는 안전한 데이터베이스로 전송되었기 때문이다.

 TRACE

클라이언트가 어떤 요청을 할 때, 그 요청은 방화벽, 프락시, 게이트 웨이 등의 애플리케이션을 통과할 수 있다.
- 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 보여준다.
- 목적지 서버에서 루프백(loopback) 진단을 시작한다.
TRACE 응답의 엔티티 본문에서는 서버가 받은 요청이 그대로 들어 있다고 합니다.
감히 잡히지 않아서 스프링 부트를 이용해서 돌려봤다.

@RequestMapping(value = "/api", method = RequestMethod.TRACE)
  public String trace() {
    return "hello";
  }

 TRACE의 엔티티 본문에는 서버가 받은 요청이 그대로 들어있다고 한다.
이게 무슨 말일까?
아쉽게도 springbootTest에서는 trace를 지원하지 않는다. ㅜㅜ
다행스럽게도 다음과 같은 코드를 작성하면 된다.

@Test
void trace_() throws Exception {
  mockMvc.perform(request(HttpMethod.TRACE, "/api"))
      .andExpect(status().isOk())
      .andDo(print());
}

놀랍게도 결과는...

이렇게 나왔다. 위에서 서버가 받은 요청이라고 했으니..
<메서드> <요청 URL> <버전> 이런식으로 나오는것을 알 수 있다.
결국 TRACE는 본문을 통해 어떤 요청이 들어 왔는지 알아보기 위해 만들어진거라 할 수 있다.

 OPTIONS

웹서버가 지원하는 메소드의 범위를 알 수 있다.
서버에게 어떤 메소드가 지원하는지 물어본다고 하는데.. 
- 여러 리소스에 대해 실제로 접근하지 않고도 그것을 어떻게 접근하는 것이 최선인지 확인할 수 있는 수단을 클라이언트
 애플리케이션에게 제공한다.

이것도 돌려보자.

확인결과 모든 것을 허용한다고 한다. 
그러면 이것을 강제할 수 는 없을까?

 DELETE

누가 봐도 URL(리소스)를 삭제하는거다.

근데 아쉽게도 PATCH가 존재하지 않는다 ㅜㅜ
PATCH는 나중에 나온걸까?

PATCH

 

PATCH - HTTP | MDN

HTTP PATCH 메소드는 리소스의 부분적인 수정을 할 때에 사용됩니다.

developer.mozilla.org

문서 전체의 완전한 교체를 허용한다고 한다.
어떻게 보면 PUT과 같은 느낌인데 PUT과 달리 멱등성을 가지 않는다고 합니다.
멱등성을 가지지 않는다말은
동일한 URL을 사용했음에도 불구하고 다른 결과를 야기 시킬 수 있다고 합니다. 그래서 사이드 이팩트가 나온다고 하는 것같다.
그럼 언제 사용할까요?

제가 생각할때는 같은 리소스에 접근 하고 그것이 항상 같은 결과를 리턴시키지 않아야 될때 사용이 되어질것 같습니다.
일부를 수정할때? 아니면 전체를 수정할때.. 이에 대해 조금더 생각해봐야겠지만...
개인적으로 일부를 수정될때 이용될것 같습니다.
왜냐하면 위에서 사이드 이펙트가 발생할 수도 있다고 했으니, 이를 최소한으로 줄어야 합니다.
즉, 변화하는 곳이 최대한 적을때 이것을 사용해야 사이드 이팩트를 최소화 할 수 있다고 생각합니다.  

확장 메서드

HTTP는 필요에 따라 문제가 없도록 설계 되있다고 한다.
다행히 새로 기능을 추가해도 과거에 구현된 소프트웨어들의 오동작을 유발하지 않는다.

솔직히 어떻게 만드는지는 잘 모르겠으나...
나중에 기회가 되면 만들어보고 싶다.
최대한 관용적으로 만드는 것이 좋을 것 같다.

상태 코드

상태코드는 크게 5개로 구분되어진다.
상태 코드는 클라이언트에게 그들의 트랜잭션을 이해할 수 있는 쉬운 방법을 제공한다.

상태코드는 사유구절과 함께 작성이 되어지는데.. 정확히 어떤식으로 써야 되는지에 대한 가이드는 없다고 한다.
다행히 추천하는 방법이 있다고 하니 그것과 함께 작성하는 편이 좋을 것 같다.

 100~199: 정보성 상태 코드

- http/1.1에 도입됨
- 복잡함을 감수할 만한 가치가 있는지에 논란이 있는 편

여기에는 2개밖에 없는 것 같다.
100 contiue 요청의 일부가 받아들어졌으며, 클라이언트는 나머지 요청을 계속 이어서 보내야함을 의미한다.
이것을 보낸뒤, 서버는 반드시 요청을 받아 응답해야 한다.
101 Swiching Protocol 서버가 프로토콜을 바꾸었음을 의미한다.

책에는 100 continue가 혼란스러운 이유에 대해 설명했지만, 지금의 나로써는 아직 어려운 것 같다.
나중에 여기는 한 번 정리할 필요가 있다고 생각이 든다. (하지만 안할 가능성이 더 높음ㅎ)

 200~299: 성공 상태 코드

이것은 성공이다. 이번에도 간단히 정리해보자.
200 OK 요청은 정상이구 본문은 요청된 리소스를 포함하고 있다.
201 Created 서버 객체를 생성하라는 요청
202 Accepted 요청은 받아졌으나 서버는 아직 처리할 준비가 되있지 않는다.
203 Non-Authoritative Information 엔티티 헤더 정보가 서버에 존재하는것이 아닌 다른 중재자가 그 정보를 대신 가지고 있다. 
204 No Content 응답 메시지는 헤더와 상태줄은 포함하지만, 엔티티 본문은 포함하지 않는다.
         -> 주로 웹 브라우저를 새 문서로 이동시키지 않고 갱신 하고자 할때 사용한다.
205 Rest Content 브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우라고 말한다.
206 Partial Content 부분 혹은 범위 요청이 성공했다.

몇개는 자주 사용하는 것들이지만 몇 개는 아리송한것들이 더 많은 것 같다. 
솔직히 이렇게 정리하는 것이 맞는지도 잘 모르겠다. 

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

클라이언트가 관심있어야 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 그 리소스의 내용 대신 다른 대안 응답을 제공한다.
만약, 리소스가 옮겨졌다면, 클라이언트에게 리소스가 옮겨졌으며, 어디서 찾을 수 있는지 알려주기 위해 리다이렉션 상태 코드와 Location  헤더를 보낼 수  있다.

보통은 회원가입같은 곳에서 이뤄지는데...
리다이렉션을 하게되면 그 페이지로 리로드하게된다. 
그럼 리로드를 했기 때문에 데이터도 정상적으로 보이게 될것이다.
만약 리로드가 안 했다고 가정해보면, 브라우저는 어떤 페이지를 보여줘야 할까?
회원가입 전? 회원가입 후?...

아래는 리다이렉션에 관한 위키글이다.
https://ko.wikipedia.org/wiki/URL_%EB%A6%AC%EB%8B%A4%EC%9D%B4%EB%A0%89%EC%85%98

 

URL 리다이렉션 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전.

ko.wikipedia.org

이것도 짧게 어떤것이 존재하는지 알아보자.
300 Muliple Choices 클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청한 경우, 그 리소스의 목록과 함께 반환한다.
301 Moved Permanetly 요청한 URL이 옮겨졌을 때 사용한다. 
302 Found 301 상태 코드와 같다. 응답은 Location 헤더에 현재 리소스가 존재하고 있는 URL을 포함해야 한다.
303 See Other 주 목적은 POST 요청에 대한 응답으로 클라이언트에게 리소스의 위치를 알려주는 것이다.}
304 Not Modified 클라이언트는 헤더를 이용해 조건부 요청을 만들 수 있다.
305 Use Proxy 리소스가 반드시 프락시를 통해서 접근되어야 함을 나타내기 위해 사용한다.
306 현재 사용하지 않음
307 Temporary Redirect 301코드와 비슷하다. 클라이어트는 Location 헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용해야 한다. 이후의 요청은 원래 URL을 사용해야 한다.

302,303,307 코드가 유독 비슷해 보이는 이유는
HTTP/1.0과 HTTP/1.1 애플리케이션이 상태 코드를 다루는 방식의 차이점에 기인한다고 한다.
결국, HTTP/1.1에서 혼란이 발생했는데
이를 해결하고자 302 상태코드 대신 307 상태코드를 사용하라고 한다.
물론 클라이언트가 HTTP/1.0을 사용할지도 모르기 떄문에 302코드도 남겨둔다고 한다.

비슷한 역할을 하지만 302는 HTTP/1.0 307을 사용한다.
서버는 리다이렉트 응답에 들어갈 가장 적절한 리다이렉트 상태 코드를 선택 하기 위해 클라이언트의 HTTP 버전을 검사할 필요가 있다. 

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

모든 에러를 서버에서 만들지는 않는다.
때로는 클라이언트 쪽에서 에러를 만들 수 있다.
어떻게 보면 사용자의 실수를 미연에 방지함으로 인해 사용자들에게 
보다 좋은 환경을 제공하는것에 있다.

이번에도 에러 상태코드가 어떤것이 존재하는지 알아보자.
400 Bad Request 클라이언트가 잘못된 요청을 보냈다고 말해준다.
401 Unauthorized 리소스를 보고 싶으면 인증을해라.
403 Payment Required 리소스를 보고 싶으면 돈을 내라 .. (현재 사용 안함)
404 Not Found 리소스를 찾지 못함
405 Method Not Allowed 지원하지 않은 메서드로 요청 받았을때 알려준다.
406 Not Acceptable 주어진 URL에 대한 리소스가 클라이언트가 받아드릴 수 없는 경우 사용한다.
407 Proxy Authentication Required 401 상태코드와 같으나, 프락시 서버를 사용한다.
408 Request Timeout 클라이언트의 요청을 완수하기에는 시간이 너무 많이 걸린다.
409 Conflict 중복된 리소스가 존재한다.
410 Gone 404와 같으나, 서버관리자가 클라이언트에게 리소스를 제거했다고 알려줄때 사용한다.
411 Length Requied 서버가 요청 메시지에 Content-Length 헤더가 있을 것을 요구할때 사용한다.
412 Precondition Failed 클라이언트가 조건부 요청을 했는데, 그중하나가 실패했을 때 사용한다.
413 Request Entity Too Large 서버가 처리할 수 있는 혹은 처리하고자 하는 한계를 넘는 크기의 요청 URL이 포함된 요청을 클라언트가 보낼때 사용한다.
414 Request URL Too Long 서버가 처리할 수 있는 혹은 처리하고자 하는 한계를 넘은 크기의 요청 URL이 포함된 요청을 클라인트가 보낼때 사용한다.
415 Unsupported Media Type 서버가 이해하거나 지원하지 못하는 내용 유형의 엔티티를 클라인트가 보낼때 사용한다.
416 Requested Range Not Satisfiable 요청 메시지가 리소스의 특정 범위를 요청했는데, 그 범위가 잘못되거나 맞지 않을 때 사용한다.
417 Expectation Failed 요청에 포함된 Expect 요청 헤더에 서버가 만족시킬 수 없는 기대가 담겨 있는 경우 사용한다.

500~599: 서버 에러 상태 코드

드디어 마지막입니다.
위는 사용자가 잘못된 방향으로 가지 않게 도와주는 역할을 한다면,
이건 서버에 문제가 발생해서 생긴 에러라고 할 수 있습니다.

만약, 이 에러코드를 보시면 당장 고쳐야 합니다.
400번대 에러코드는 개발자가 의도적으로 발생시킨 에러지만,
500번대는 개발자도 모르는 에러이기 때문입니다.

마지막으로 500번대도 알아봅시다.

500 Internal Server Error 서버가 요청을 처리할 수 없게 만드는 에러를 만났을 때 발생
501 Not Implemented 클라이언트가 서버의 능력을 넘는 요청을 했을 때 발생
502 Bad Gateway 프락시나 게이트웨이처럼 행동하는 서버가 그 요청 응답 연쇄에 있는 다음 링크로 부터 가짜 응답에 막닥뜨렸을때 발생
503 Service Unavailable 현재는 요청을 처리할 수 없지만, 나중에는 가능함을 의미하고자 할때 발생
504 Gateway Timeout 상태코드 408과 유사 다른 서버에게 요청을 보내고 응답을 기다리다 타임아웃이 발생한게 게이트웨이나 프락시일때 
505 HTTP Version Not Supported 서버가 지원할 수 없거나 지원하지 않으려고 하는 버전의 프로토콜로된 요청을 받았을 때 발생 

헤더

헤더와 메서드는 클라이언트와 서버가 무엇을 하는지 결정하기 위해 사용된다.
그러니까 메서드를 보고 리소스를 어떻게 할지 결정을 합니다.
가령 GET은 리소스를 가져온다는 든지, POST는 데이터를 전송한다는 등, 이런것들로 클라이언트의 요청을 서버가 
처리할 수 있다고 생각합니다.
위에서 헤더도 메소드와 마찬지로 클라이언트와 서버가 무엇을 하는지 결정을 한다면,
메소드와 하는 역할은 달라도 비슷한 부분은 있지 않을까요?

지금부터 헤더의 종류에 대해 알아봅시다.

 일반 헤더

- 클라이언트와 서버 둘다 사용
- 클라이언트, 서버 그리고 어딘가에 메시지를 보내는 다른 애플리케이션들을 위해 다양한 목적으로 사용된다.

아주 기본적인 헤더...
응답과 요청 모두 같은 의미를 가질때? 

 일반 헤더가 어떤것이 있는지 알아보자.

Connection 클라이언트와 서버가 요청/응답 연결에 대한 옵션을 정할 수 있게 해준다.
Date 메시지가 언제 만들었는지 날짜를 알게 해준다.
MIME-Version 발송자가 사용한 MIME의 버전을 알려준다.
Trailer chunked transfer 인코딩으로 인코딩된 메시지의 끝 부분에 위치한 헤더들의 목록을 알려준다.
Transfer-Encoding 메시지에 어떤 인코딩이 적용되었는지 말해준다.
Upgrade 발송자가 '업그레이드'하길 원하는 새 버전이나 프로토콜을 알려준다.
Via 이 메시지가 어떤 중재자를 거쳐 왔는지 보여준다.

일반 캐시 헤더

HTTP/1.0은 HTTP 애플리케이션에게 매번 원 서버 부터 객체를 가져오는 대신 로컬 복사본으로 캐시할 수 있도록 해주는 헤더를 도입했다.

캐시는 추후에 학습한다.

Cache-Control 메시지와 함께 캐시 지시자를 전달하기 위해 사용
Pragma 메시지와 함께 지시자를 전달하는 또 다른 방법. 캐시에 국한 되지 않는다.

 요청 헤더

 - 누가봐도 클라이언트가 서버에 요청을 보낼때 사용이 되어진다.
 - 서버에게 클라이언트가 받고자 하는 데이터의 타입이 무엇인지와 같은 부가 정보를 제공한다.

Client-IP 클라이언트가 실행된 컴퓨터의 IP를 제공한다.
From 클라이언트 사용자의 메일 주소를 제공한다.
Host 요청의 대상이 되는 서버의 호스트 명과 포트를 준다.
Referer 현재의 요청 URI가 들어있었던 문서의 URL을 제공한다.
UA-CPU 클라이언트CPU의 종류나 제조사를 알려준다.
DA-Disp 클라이언트의 디스플레이(화면)능력에 대한 정보를 제공한다.
DA-OS 클라이언트 기기에서 동작 중인 운영체제의 이름과 버전을 알려준다.
PA-Pixels 클라이언트 기기 디스플레이에 대한 픽셀 정보를 제공한다.
User-Agent 요청을 보낸 애플리케이션의 이름을 서버에 말해준다.

Accept 관련 해더

클라이언트가 무엇을 원하고 무엇을 할 수 있는지, 그리고 무엇보다도 원치 않는 것은 무엇인지 알려 줄 수 있다.
이것을 이용해서 클라이언트와 서버가 윈윈할 수 있다고 생각한다.
왜냐하면 서버가 클라이언트가 무엇을 보내야하는지 알기 때문에 똑똑한 결정을 할 수 있기 때문이다.

Accpet 서버에게 서버가 보내도 되는 미디어 종류를 말해준다.
Accpet-Charset 서버에게 서버가 보내도 되는 문자집합을 말해준다.
Accept-Encoding 서버에게 서버가 보내도 되는 인코딩을 말해준다.
Accept-Language 서버에게 서버가 보내도 되는 언어를 말해준다.
TE 서버에게 서버가 보내도 되는 확장 전송 코딩을 말해준다.

조건부 요청 헤더

클라이언트는 서버에게 조건에 따라 서로다른 요청을 원할 수 도 있다. 
이럴때 사용되는 것이 조건부 요청 헤더이다.

Expect 클라이언트가 요청에 필요한 서버의 행동을 열거할 수 있게 해준다.
if-Match 문서의 엔티티 태그가 주어진 엔티티 태그와 일치하는 경우에만 문서를 가져온다.
if-Modified-Since 주어진 날짜 이후에 리소스가 변경되지 않았다면 요청을 제한한다.
if-None-Match 문서의 엔티티 태그가 주어진 엔티티 태그와 일치하지 않는 경우에만 문서를 가져온다.
if-Range 문서의 특정 범위에 대한 요청을 할 수 있게 해준다.
if-Unmodified-Since 주어진 날짜 이후에 리소스가 변경되었다면 요청을 제한한다.
Range 서버가 범위 요청을 지원한다면, 리소스에 대한 특정 범위를 요청한다. 

요청 보안 헤더

- 클라이언트가 인증 요구/응답을 요청할때 
- 보다 안전하게 리소스에 만들 수 있다.

Authorization 클라이언트 서버에게 제공하는 인증 그 자체에 대한 정보를 담고 있다.
Cookie 클라이언트가 서버에게 토큰을 전달할 때 사용한다. 
Cookie2 요청자가 지원하는 쿠키의 버전을 알려줄 때 사용한다.

프락시 요청 헤더

- 프락시에 관한 요청을 할때 사용

Max-Forward 요청이 원 서버로 향하는 과정에서 다른 프락시나 게이트웨이로 전달될 수 있는 최대 횟수
Proxy-Authorization Authorization과 같으나 프락시에서 인증할 때 사용한다.
Proxy-Connection Connection과 같으나 프락시에서 연결을 맺을 때 사용한다.

응답 헤더

  - 서버가 클라이언트에게 응답을 보낼때 사용된다.
  - 응답 헤더는 클라이언트에게 부가 정보를 제공한다.
  - 클라이언트가 응답을 잘 다루고 있고, 추후에 요청을 잘 보낼 수 있게 도와준다.

Age 응답이 얼마나 오래 되었는지
Public 서버가 특정 리소스에 대해 지원하는 요청 메서드의 목록
Retry-After 현재 리소스가 사용 불가능한 상태일 때, 언제 가능해지는지 날짜 또는 시간
Server 서버 애플리케이션의 이름과 버전
Titile HTML 문서에서 주어진 것과 같은 제목
Warning 사유 구절에 있는 것보다 더 자세한 경고 메시지

협상 헤더

클라이언트가 여러가지로 표현이 가능한 상황이라면 (가령 HTML 문서가 프랑스어와 독일어로 표현 가능한 상황)
서버와 클라이언트는 협상을 통해 어떤 것을 취할지 결정한다.

Accept-Ranges 서버가 자원에 대해 받아들일 수 있는 범위의 형태
Vary 서버가 확인해 보아야 하고 그렇기 때문에 응답에 영향을 줄 수 있는 헤더들의 목록

응답 보안 헤더

Proxy-Authenticate 프락시에서 클라이언트로 보낸 인증요구의 목록
Set-Cookie 서버가 클라이언트를 인증할 수 있도록 클라이언트 측에 토큰을 설정하기 위해 사용한다.
Set-Cookie2 Set-Cookie와 비슷 RFC 2965에 정의 된 쿠키
WWW-Authenticate 서버에서 클라이언트로 보낸 인증요구의 목록

엔티티 헤더

   - 엔티티 본문에 대한 헤더
   - 예를들어 엔티티 본문이 어떤 타입인지 명시할때 Content-type: text/html ...

엔티티와 그것의 내용물에 대한, 개체의 타입부터 시작해서 주어진 리소스에 대해 요청할 수 있는 유효한 메서드들까지,
광범위한 정보를 제공한다.

Allow 이 엔티티에 대해 수행할 수 있는 요청 메서드들을 나열한다.
Location 클라이언트에게 엔티티가 실제로 어디에 위치하고 있는지 말해준다.

콘텐츠 헤더

- 엔티티에 대한 구체적인 정보를 제공한다.

Content-Base 본문에서 사용된 상대 URL을 계산하기 위한 기져 URL
Content-Encoding 본문에 적용된 어떤 인코딩
Content-Language 본문을 이해하는데 가장 적절한 자연어
Content-Length 본문의 길이나 크기
Content-Location 리소스가 실제로 어디에 위치하는지
Content-MD5 본문의 MD5 체크섬
Content-Range 전체 리소스에서 이 엔티티가 헤당하는 범위를 바이트 단위로 표현
Content-Type 이 본문이 어떤 종류의 객체인지

엔티티 캐싱 헤더

- 언제 캐시가 되어야 하는지에 대한 지시자를 제공
ex) 리소스에 대해 캐시된 사본이 아직 유효한지 정보와, 캐시된 리소스가 더 이상 유효하지 않게 되는 시점을 더 추정하기 위한 단서 같은거

eTag 이 엔티티에 대한 엔티티 태그
Expires 이 엔티티가 더 이상 유효하지 않아 원본을 다시 받아와 하는 일시
Last-Modified 가장 최근에 이 엔티티가 변경된 일시

확장 헤더

 - 비 표준 헤더
 - 만약 사용한다면 신중을 기려서 사용해야 된다.

추가 정보
https://datatracker.ietf.org/doc/html/rfc2616  
https://www.w3.org/Protocols/   

반응형

'WEB > http' 카테고리의 다른 글

프록시  (0) 2021.07.20
웹 서버  (0) 2021.07.05
커넥션 관리  (2) 2021.06.22
URL과 리소스  (0) 2021.05.26
HTTP 개관  (0) 2021.05.19

댓글

Designed by JB FACTORY