HTTP 박살내기 프로젝트 - 3 | HTTP 헤더

* 본 게시글은 <HTTP 완전 가이드> 서적을 적극 참고하여 작성하였습니다.

 

# 헤더

헤더와 메서드는 클라이언트와 서버가 무엇을 하는지 결정하기 위해 함께 사용된다.

헤더는 크게 5가지로 분류된다.

 

1. 일반 헤더 (General)

- 클라이언트, 서버 양쪽 모두 사용

- 클라이언트, 서버, 메시지를 보내는 애플리케이션들을 위한 다양한 목적으로 사용.

 

2. 요청 헤더 (Request)

- 요청 메시지를 위한 헤더 (클라언트 단에서 전송)

- 서버에게 클라이언트가 받고자 하는 데이터의 타입이 무엇인지같은 부가 정보 제공

 

3. 응답 헤더 (Response)

- 클라이언트에게 정보를 제공하기 위한 헤더 (서버 단에서 전송)

 

4. 엔티티 헤더 (Entity)

- 엔티티 본문(메시지 본문)에 대한 헤더 

- 엔티티 본문에 들어있는 데이터의 타입이 무엇인지같은 부가 정보 제공

 

5. 확장 헤더 (Extension)

- 애플리케이션 개발자들에 의해 만들어진 비표준 헤더. 

 

 

# 일반 헤더

메시지에 대한 아주 기본적인 정보 제공. - 메시지 종류와 무관하게 유용한 정보 제공.

 

<종류>

Connection - 클라이언트와 서버가 요청/응답 연결에 대한 옵션을 정할 수 있게 해줌.

    > Connection : close           = 이 HTTP 메시지 이후 연결을 끊습니다

    > Connection : keep-alive    = TCP 연결을 계속 유지합니다

Date - 메시지 생성 날짜, 시간

 

<캐시 헤더>

Cache-Control - 메시지와 함께 "캐시 지시자"를 전달.

Pragma - 메시지와 함께 지시자를 전달하는 또 다른 방법. (캐시에 국한 X)

 

<컨텐츠 헤더> 

엔티티의 컨텐츠에 대한 구체적인 정보를 제공한다

- POST 요청 시 포함

- 응답시 포함 등...

 

Content-Type

Content-Encoding

-- (스프링에서 서블릿을 다룰때 응답 메시지에 위 두개 헤더만 넣으면 아래것은 자동으로 처리한다)

Content-Language

Content-Length

Content-Range 등...

 

ContentType, CharcterEncoding만 정해주면 된다.

 

# 요청 헤더

요청 헤더는 요청 메시지에서만 의미를 갖는다. 누가 요청을 보냈는지, 어떤 정보를 원하는지에 대한 정보를 담는다.

 

<종류>

User-Agent - 요청을 보낸 애플리케이션의 이름, 정보.

From - 클라이언트 사용자의 메일 주소 제공

Host - 요청의 대상이 되는 서버의 호스트 명과 포트 제공 (필수 포함)

Referer - 현재의 요청 URI가 들어있었던 문서의 URL 제공 (-> 유입 경로 분석 가능)

 

<Accept 관련 헤더 (협상 헤더)>

클라이언트는 Accept 헤더를 이용해 서버에게 자신이 선호하는 정보를 요청한다.

 

Accept : 미디어 타입

Accept-Charset : 문자집합

Accept-Encoding : 인코딩 방식

Accept-Language : 언어 (kr)

 

* 협상 헤더는 서버와 클라이언트가 어떤 표현을 택할것인지 우선순위를 정할 수 있다

    1. 0~1 순으로 숫자가 높을수록 우선순위가 높다 (아래 사진 참조)

    2. 구체적인 표현이 더 우선순위가 높다

 

<조건부 요청 헤더>

요청에 제약조건을 거는 방법.

If-Match, Except, If-Modified-Since 등..

 

<요청 보안 헤더>

Authorization - 클라이언트가 서버에게 제공하는 인증 그 자체에 대한 정보

Cookie - 클라이언트가 서버에게 쿠키를 전달할 때 사용

 

# 응답 헤더

응답 메시지가 가지고 있는 헤더. 클라이언트에게 부가정보 제공,

 

<종류>

Age - 응답이 얼마나 오래되었는지

Server - 서버 애플리케이션의 정보

Retry-After - 현재 리소스가 사용불가 상태일때, 언제 다시 접근 가능해지는지에 대한 정보

 

<응답 보안 헤더>

Set-Cookie - 서버가 클라이언트를 인증할 수 있도록 클라이언트 측에 쿠키를 설정한다

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

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

 

<협상 헤더>

Accept-Ranges - 서버가 자원에 대해 받아들일 수 있는 범위의 형태

Vary - 서버가 확인해봐야하는 헤더들의 목록

 

<엔티티 헤더>

Location - *리다이렉트시 사용* - 수신자에게 새로운 위치를 알려줄 때 사용

Allow - 이 엔티티에 대해 수행될 수 있는 요청 메서드를 나열. 허용가능한 HTTP 메소드 목록.

 

<엔티티 캐싱 헤더>

Expires - 캐시 만료일시

Last-Modified - 가장 최근 엔티티가 변경된 일시

 

---

이제 개발자 도구를 이용해 실제 요청, 응답 헤더를 까보면서 살펴보자

<요청 헤더>

<응답 헤더>

 

---

뭐 이렇게 많이 알아봤지만 굳이 모든 헤더를 다 꿰고 살 필요는 없지 않을까 싶다.

 

우리에겐 구글이 있으니까 :D

 

 

+) Content-Type 헤더, Accept 헤더 활용 사례

 

    @PostMapping(value = "/mapping-consume", consumes = MediaType.APPLICATION_JSON_VALUE)
    public String mappingConsumes() {
        log.info("mappingConsumes");
        return "ok";
    }

 

# consumes 옵션

HTTP POST 요청 시 Content-Type 헤더가 Application/Json인 경우에만 매핑해서 처리한다.

 -> 응답 측에서 해당 데이터 타입을 처리할 로직이 없으면 튕궈내는게 당연한 이치

 

이러면

요청을 튕궈버린다

..

조건에 맞다면

OK!

 

    @PostMapping(value = "/mapping-produce", produces = MediaType.TEXT_HTML_VALUE)
    public String mappingProduces() {
        log.info("mappingProduces");
        return "ok";
    }

 

# produces 옵션

HTTP POST 요청 시 Accept 헤더가 text/html 인 경우에만 매핑해서 처리한다.

-> 내가 처리하는(=생산하는=produce) 데이터 타입이 클라이언트가 원하는 타입과 다르면 튕궈내는것도 당연한 이치