HTTP 웹 기본 지식_HTTP 일반 헤더

HTTP 헤더 개요

HTTP 헤더의 용도란 HTTP 전송에 필요한 모든 부가정보가 들어가 있는 것이다.
표준 헤더는 많고도 많다..필요시 임의의 헤더도 추가가 가능하다고 한다.
과거에는 General 헤더, Request 헤더, Response 헤더, Entity 헤더로 구분했다.

그런데.. 2014년 RFC7230~ 7235의 등장으로 엔티티 -> 표현. 표현 = 표현 메타데이터 + 표현 데이터로 변화.
메시지 본문을 통해 표현 데이터를 전달하고 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공하는..그런거..

 

표현

구체적으로 표현에 대해 하나씩 알아보도록 하자. 먼저 표현 헤더는 전송, 응답 둘 다 사용한다는 것 잊지 말기!

Content-Type은 표현 데이터 형식의 설명으로 미디어 타입, 문자 인코딩 등이 들어갈 수 있다.
예로는 text/html; charset=utf-8, application/json, image/png 이런 것들이 있다.
Content-Encoding은 표현 데이터를 압축하기 위해 사용하는 것으로,
전달하는 곳에서 압축 후 인코딩 헤더 추가하고 읽는 쪽에서는 헤더 정보로 압축 해제.
Content-Language는 표현 데이터의 자연 언어로 ko, en 등이 있다.
외국 사이트 들어가서 한국어로 보고 싶을 때? 이럴 때 유용하다고 한다.
Content-Length는 표현 데이터 길이로 바이트 단위이다.
Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안 된다고 하는데 구체적인 건 뒤에서 알아보자.

 

콘텐츠 협상

콘텐츠 협상이란 클라이언트가 선호하는 표현을 요청하는 것으로
Accept, Accept-Charset, Accept-Encoding, Accept-Language 총 4가지 속성들이 있다고 볼 수 있다.
이런 협상 헤더는 요청 시에만 사용할 수 있다.

협상과 우선순위와 관련해서 먼저 Quality Values(q) 값 사용에 대해 알아보도록 하자. 
0 ~ 1 사이의 값이고 클수록 높은 우선순위를 가지며 생략 시는 값이 1이라고 생각하면 된다.

두 번째와 세 번째는 구체적인 것이 우선, 구체적인 것을 기준으로 미디어 타입을 맞춘다.

 

전송 방식

- 단순 전송 : 길이 알 수 있을 때로 content-length 지정. 말 그대로 단순하게 요청해서 한 번에 쭉 전송하고 쭉 받기.
- 압축 전송 : Content-encoding 타입을 꼭 적어줘야 하는 전송 방식.
- 분할 전송 : content-length를 넣으면 안 된다.
  왜???? length가 예상이 안되기 때문이기도 하고 분할해서 하면 각 chunck마다 byte 정보가 다 있어서이다.

- 범위 전송 : 말 그대로 특정 범위 Content-Range에 지정.

 

일반 정보

From :  유저 에이전트의 이메일 정보로 검색 엔진 같은 곳에서 주로 사용하나 일반적으로 잘 사용되지 않는다.
Referer : 이전 웹 페이지 주소로 A -> B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청한다.
이것으로 유입 경로 분석이 가능하고 요청에서 사용한다.
User-Agent : 클라이언트의 애플리케이션 정보로 어떤 종류의 브라우저에서 장애가 발생하는지 파악이 가능하다.
Server : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보로 응답에서 사용한다.
Date : 메시지가 발생한 날짜와 시간으로 응답에서 사용한다.

 

특별한 정보

Host : 요청한 호스트 정보(도메인)로 필수 값이다.

Location : 페이지 리다이렉션. 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면 이 위치로 자동 이동한다.
Allow : 허용 가능한 HTTP 메서드로 405(Method Not Allowed)에서 응답에 포함해야 한다.
Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간으로 날짜 표기 혹은 초단위표기로 할 수 있다.

 

인증

Authorization : 클라이언트 인증 정보를 서버에 전달한다.
WWW-Authenticate : 리소스 접근 시 필요한 인증 방법을 정의하는 것으로 401 Unauthorized 응답과 함께 사용한다.

 

쿠키

Set-Cookie : 서버에서 클라이언트로 쿠키 전달한다.
Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청 시 서버로 전달한다.
쿠키를 미사용하게 된다면..??? 아래와 같은 현상이 발생할 수 있다.

대안으로 모든 요청과 링크에 사용자 정보를 포함한다 하면??
개발 과정에서 일일이 값을 넘겨줘야 하고 브라우저를 완전히 종료하고 다시 열면 그때는??
그래서 쿠키가 필요하다고 하는 것이다!

쿠키의 예는 아래와 같이 볼 수 있다.

set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure

제일 쉽게 생각할 수 있는 사용은 사용자 로그인 세션 관리 시, 광고 정보 트래킹 시에 사용할 수 있다.
또한 쿠키 정보는 항상 서버에 전송되기 때문에 네트워크 트래픽을 유발할 수 있으므로 최소한 정보만 사용하자.
서버에 전송하지 않고 웹 브라우저 내부에 데이터를 저장하고 싶다면 웹 스토리지도 참고해보자.
주의할 점으로는 보안에 민감한 주민번호, 신용카드 정보 같은 것들은 저장하면 안 된다!

쿠키의 생명주기로는 만료일이 되면 쿠키 삭제하는 expires, 
특정 초를 계산해서 작성하거나 0이나 음수를 지정하면 쿠키 삭제하는 max-age가 있다.

쿠키의 도메인으로는 명시한 문서 기준 도메인과 서브 도메인까지 포함하거나,
현재 문서 기준으로 도메인만 적용하는 두 가지가 있는데,
서브 도메인까지 포함할 경우 domain = ________ 이런 식으로 작성해주자.

쿠키의 경로로는 일반적으로 하위 경로 페이지까지만 쿠키 접근 가능하게 하고 path = /(루트) 이런 식이다.

쿠키의 보안으로는 http, https를 구분하지 않고 전송하는 Secure,
XSS 공격 방지하면서 자바스크립트에서 접근 불가하게 하는 HttpOnly,
CSRF 공격 방지하면서 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송하는 SameSite가 있다.

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의