크롬 개발자 도구로 보는 HTTP 헤더 알아보기

Nanotube·2021년 8월 30일

HTTP

목록 보기

6/11

원래 개발자 라면 알고있어야 할 내용이지만, 그동안 간과했던 사항으로 새 프로젝트를 한다며 새로 접하는 라이브러리를 활용하며 성장한다고 느꼈지만, 사실 기초(기반)이 부실한채로 쌓아올리는 건축물처럼 언제 무너질지도 모르는채 의미없는 프로젝트만 진행했었다.

요새 내가 너무 안일했다고 느끼며, 기초적인 부분으로 다시 복귀하여 HTTP 헤더와 바디의 구조 그리고 Req.body, req.params의 각 차이점을 다시 알아보려한다.

HTTP 통신 헤더 알아보기

우선 HTTP 통신을통해

클라이언트는 서버에 요청을, 서버는 요청에 대한 응답을 보내게 되는데 이 통신에서 들어가는 헤더들을 알아보고자 한다.

크럼창을 열어 특정 페이지에 접속하여 F12키를 입력해서 개발자도구를 열어보자

그리고 Network탭에서 가장 위에서 생성된 www.tistory.com을 확인 해 볼 수 있는데, 주소창에 https를 http로 바꿔서 보면 더욱 자세히 볼 수 있다.

HTTP 헤더란?

HTTP 메세지중 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송하며, HTTP 헤더는 대소문자를 구분하지 않는 이름과 콜론(:) 그리고 값으로 이루어져있다.

특히 쿠키나 세션방식의 인증방식을 사용할 때, 토큰을 헤더에 실어 전달한다.

시작 줄 (Start Line)

시작줄은 HTTP 요청과 응답으로

요청에는 3가지 동작으로 나뉜다.

A. HTTP 메소드 (GET, PUT, POST, OPTION)등
B. 요청의 타겟 URL이 들어간다. 예를들어 루트 도메인은 /,
C. HTTP 프로토콜의 버전이 들어간다. 현제는 기본적인 HTTP1.1

응답에는 3가지 동작으로 나뉜다.

A. 프로토콜 버전 (HTTP/1.1)
B. 요청의 성공 여부를 상태코드로 나타냄 (200, 404, 302)
C. 상태 텍스트를 나타냄 (Not Found)

공통 헤더(General Header)

Date : HTTP 메세지가 만들어진 시각이다.
Connection: HTTP/1.1을 사용하는데 기본적으로 Keep-alive로 적용되어있다. 접속 유지 여부라서 큰 의미는 없다.

Cache-Control을 알기전에 브라우저의 캐시란 무엇인가?

간단히 말해서 서버 지연을 줄이기 위해 정적인 에셋(Image, HTML, CSS, JS), 즉 사본을 임시저장 하기위한 기술로서 웹 캐시의 일종이다.

Cache-Control: HTTP/1.1 부터 도입된 헤더이며, 설정가능한 여러 옵션이 존재한다.
- no-cache: 브라우저가 캐시를 참조하지 않고, 서버에 대해 컨텐츠 유효성을 검사하도록 지시한다. 즉 서버에서 캐시 저장여부를 물어본다.
- no-store: 아무것도 캐싱하지 않겠다는 내용.
- must-revalidate: 만료된 캐시만 서버에 확인을 받도록 한다.
- public: 컨텐츠를 공개한다. 브라우저외에 중개 서버에 저장 허용.
- private: 특정 사용자 환경(오직 브라우저)에만 캐시 저장허용.
- max-age: 캐시 유효시간을 설정한다. 초(seconds)단위로 값을 할당 한다.
- s-maxage: 공유캐시에서만 동작하며, Max-age, Expires 헤더를 재정의한다.

cache-control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Expires: 응답 컨텐츠가 언제 만료되었는지 나타내며, Cache-control의 max-age가 있는 경우 이 헤더는 무시된다.

엔티티 헤더(Entity Header)

Content-Length: 요청과 응답 메세지의 본문 크기를 바이트 단위로 표시해준다.
Content-Type: 컨텐츠 타입과 문자열 인코딩(utf-8 등)을 명시할 수 있다.

text/html;charset=UTF-8

Content-Language: 사용자의 언어를 뜻한다,

Content-language: en-Us

Content-encoding: 컨텐츠의 압축된 방식을 담는 헤더이다. br, gzip, deflate 등이 있으며 브라우저가 해제해서 사용한다. 데이터 소모량도 줄어들고, 요청, 응답에 대해서 전송속도도 빨라지기 때문에 압축을 권장함

요청헤더(Request Header)

HOST: 서버의 도메인 네임이 나타는 부분이다.

www.tistory.com

User-Agent: 현재 사용자가 어떤 운영체제와 브라우저를 이용해 요청을 보냈는지 나온다.

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36

Accept: 서버에 요청을 보낼 때 해당 타입(MIME)의 데이터를 보내줬으면 좋겠다고 명시할때 사용한다.

html 형식만 요청 시 Accept: text/html
텍스스트 와일드카드 Accept: text/*
이미지 특정 형식   Accept: image/png, image/gif

Authorization: 이 헤더는 인증 토큰(Basic나 Bearer 토큰)을 서버로 보낼 때 사용하는 헤더이다. 보통 Basic나 Bearer 같은 토큰의 타입과 사용자 에이전트임을 증명하는 자격을 실어서 보낸다.

Authorization: <type> <credentials>

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJ2ZWxvcGVydC5jb20iLCJleHAiOiIxNDg1MjcwMDAwMDAwIiwiaHR0cHM6Ly92ZWxvcGVydC5jb20vand0X2NsYWltcy9pc19hZG1pbiI6dHJ1ZSwidXNlcklkIjoiMTEwMjgzNzM3MjcxMDIiLCJ1c2VybmFtZSI6InZlbG9wZXJ0In0.WE5fMufM0NDSVGJ8cAolXGkyB5RmYwCto1pQwDIqo2w

Basic(RFC 7617): 사용자 아이디와 암호를 Base64로 인코딩한 값을 토큰으로 사용한다.

A. 사용자명과 비밀번호가 콜론을 이용하여 합쳐진다 ex) kimcoding:qlalfqjsgh12

B. 결과에 대한 문자열을 `Base64`로 인코딩한다 (a2ltY29kaW5nOnFsYWxmcWpzZ2gxMg==)
                                
C. 결과  Authorization: Basic a2ltY29kaW5nOnFsYWxmcWpzZ2gxMg==

Bearer(RFC 6750): OAuth나 JWT에 대한 접근을 위해 발급받는 자격증명 타입이다.

정보 교류나 회원인증을 위주로 사용하며, 헤더.내용.서명 을 기본적으로 HMAC SHA256 알고리즘을 사용하는데, base64UrlEncode(header), base64UrlEncode(payload)과 비밀키를 인코딩 한 후 검증에 활용하기 위해 쓰인다.

AWS4-HMAC-SHA256: AWS 전자 서명 기반 인증 타입이다.

Authorization: AWS4-HMAC-SHA256 
Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request, 
SignedHeaders=host;range;x-amz-date,
Signature=fe5f80f77d5fa3beca038a248ff027d0445342fe2855ddc963176630326f1024

Origin: POST 같은 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지 나타낸다. 요청 주소와 받는 주소가 다를 경우 CORS 문제가 발생한다.
Cookie: 클라이언트가 서버한테 쿠키를 보낼 때, 헤더에 담아 보낸다.

cookie: SEARCH_SAMESITE=CgQIsZMB; ab.storage.userId.7af503ae-0c84-478f-98b0-ecfff5d67750=%7B%22g%22%3A%22browser-1629963143862-c%22%2C%22c%22%3A1629963277478%2C%22l%22%3A1629963277478%7D; ab.storage.deviceId.7af503ae-0c84-478f-98b0-ecfff5d67750=%7B%22g%22%3A%22217b5680-be7a-a876-6177-b1fc3231bdda%22%2C%22c%22%3A1629963277484%2C%22l%22%3A1629963277484%7D; OTZ=6127857_20_20__20_; ....

보는 바와 같이
Cookie: <key> = <Value>, <Key> = <Value>

이런식으로 이루어져 있다.

Referer: 해당 페이지 이전의 주소가 담겨있다. 이 헤더를 사용할 경우 어떤 페이지에서 현재 페이지로 넘어왔는지 알 수 있다.
Refrrer-Policy: 크롬에서는 General Header에 속해있다. Referer는 방문시 흔적을 남기기 때문에(A에서 B에게 방문정보 전달) 전달되는 주소의 노출 정도를 정책을 정할 수 있다.

<meta name"referrer" content="이곳에 작성" />

이곳에 작성에 들어가야할 필드

no-referrer: 요청해도 referrer을 전송하지 않음.
no-referrer-when-downgrade: 대상 주소가 https 일 때만 전송한다.
origin-when-cross-origin: 같은 홈페이지 일때는 전체주소, 다른 페이지로는 도메인 주소로 보낸다.
strict-origin-when-cross-origin: 같은 홈페이지 일때는 전체 주소, 다른 https 페이지로 갈때는 도메인 주소만, http로 갈때는 referrer 전송하지 않음

응답헤더(Response Header)

Access-Control-Allow-Origin: 요청을 보내는 Client 주소와 받는 Server 주소가 다른 경우 CORS 에러를 발생한다.

특정 도메인 Access-Control-Allow-Origin::www.example.net 으로 특정 도메인을 작성하여 해결하거나 Access-Control-Allow-Origin:*으로 어느 곳에서든지 요청을 보낼수 있게 할 수 있다.

Allow:
Location : 300 혹은 201 Created 응답일 때 어느 페이지로 이동할지 알려주는 헤더

Location: https://www.tistory.com/

Pragma : HTTP/1.1의 Cache-Control 헤더가 생기기전 대용 헤더로 사용되었다. HTTP/1.0을 사용하는 클라이언트들 만을 위한 비공식적인 호환성을 위해 사용한다.

pragma: no-cache // Cache-control: no-cache와 같은 기능

Set-Cookie: 서버에서 클라이언트(브라우저)에게 해당 쿠키를 저장하라는 명령하는 헤더이다.
Set-Cookie: <key>=<Value>; Options....

server측에서 cookiePaser()라이브러리를 활용 한다면, res.cookie(key, value, option)
이런식으로 활용한다.

Cookie 옵션을 확인해보자
Expires: 쿠키 만료 날짜를 알려준다.
Max-Age: 쿠키 수명을 알려 준다.(Expires는 무시됨)
Secure: Https에서만 쿠기가 전송된다.
HttpOnly: 자바스크립트에서 쿠키에 접근할 수 없다. XSS 공격을 막기 위한 수단.
Domain: 일치한 도메인에서 요청시 쿠키가 전송된다.
Path: 경로가 일치하는 요청에서만 쿠키가 전송된다.

앞에 X가붙은 헤더

일명 커스텀 등록 헤더는 RFC 6648이라는 비표준 빌드가 표준이 되기 이전에 사용자 임의로 붙여 임의로 정의한 헤더라는 것을 설명한다. 2012년 6월에 폐기되어 지금은 사용하지 않지만 대표적으로 몇가지가 눈에 띄는 것들이 있다. 그것들을 알아보자.

X-Forwarded Series: 요청이 어디서 건너왔는지 알려주는 헤더이다. 보통 클라이언트와 서버간 2단 구조로 보다는 클라 - 중개 - 중개 - 서버 같은 다단 구조로 이루어져있기 때문에, 원래 요청이 누구였는지 밝히기 위해 사용한다.
- X-Forwarded-For: 1.1.1.1, 2.2.2.2, 3.3.3.3 이와같이 현재까지 거쳐온 서버의 IP 정보를 가지고있다.
- X-Forwarded-Host: www.google.com 원래서버의 호스트명이다.
- X-Forwarded-Proto: https 원래 서버의 프로토콜 명
- X-Frame-Options: frame, iframe, object 태그 안에서 페이지를 렌더링 하는 것을 막을 수 있다.

옵션 중 한가지를 설정할 수 있는데 다음과같다.

X-Frame-Options: DENY, : frame, ifrome, object를 안쓸 시
SAMEORIGIN, : 개인 사이트 자체를 iframe 등으로 불러오는 경우
ALLOW-FROM https//www.google.com : 특정 사이트만 불러오는 것을 허용할 때
```
         
```
X-Content-Type-Options: 서버에서 보내온 Content-Type 헤더가 잘못 설정되었다고 생각하는 경우, 브라우저는 자체적으로 컨텐츠 타입을 추론한다.

예를 들어 css파일인데 text/html로 전달 받은 경우 브라우저가 text/css로 추론이 가능하다는 뜻이다. 이러한 방법보다는 차라리 nosniff를 보내주어, 브라우저가 서버가 보낸 컨텐츠 타입을 따르게 강제할 수 있다.

X-Content-Type-Options: nosniff

ref: 제로초, W3ORG, W3ORG, MDN 쿠키, MDN 캐쉬컨트롤
,MDN Referrer.