(HTTP) 15 - HTTP 헤더 (일반 헤더)

 

HTTP 헤더에는 HTTP 전송에 필요한 모든 부가정보가 담겨 있음. 

 

 

Request 헤더 ex) 웹브라우저 정보 등

Entity 헤더 : 메세지 바디에 들어가는 정보 

 

 

메시지 본문은 엔티티 본문 전달하는데 사용되는데

엔티티 본문에는 요청이나 응답에서 전달할 실제 데이터가 들어간다. 

 

엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보를 제공한다.

ex) 데이터 유형(html, json), 데이터 길이, 압축 정보 

 

※ 엔티티 : 데이터의 집합

 

 

이전 기준이 바뀜

 

 

엔티티 용어 사라지고 -> 표현 용어가 생김

Representation(표현) = representation Metadata(표현 메타 데이터) + Representation Data(표현 데이터)

 

 

- 메세지 본문을 통해 표현 데이터를 전달

- 메세지 본문 = 페이로드(payload)

- 표현은 요청이나 응답에서 전달할 실제 데이터

- 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공

 

표현 = 표현 헤더 + 표현 데이터

 

■ 표현

 

회원이라는 리소스를 html 전달할지, json 으로 전달할지

이를 html 로 표현한다, json 으로 표현한다 라고 할 수 있다. 

 

Content-Type : 표현 데이터 형식

Content-Encoding : 표현 데이터 압축 방식

Content-Language : 표현 데이터 자연 언어 (한국어, 영어 등)

Content-Length : 표현 데이터 길이

 

표현 헤더는 전송, 응답 둘 다 사용

 

* Content-Type : 표현 데이터 형식 설명

 

- 미디어 타입, 문자 인코딩

ex) text/html; charset=utf-8

application/json (기본 uft-8 이다)

image/png

 

* Content-Encoding : 표현 데이터 인코딩

 

표현 데이터 압축하기 위해 사용

데이터 전달하는 곳에서 압축 후 인코딩 헤더 추가

데이터 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제

ex) gzip, deflate, identity

 

※ gzip : gzip은 파일 압축에 쓰이는 응용 소프트웨어

identity : 압축 안한다

 

* Content-Language : 표현 데이터 자연 언어

* Content-Length : 표현 데이터 길이

 

- 바이트 단위

- Transfer-Encoding(분할 전송 코딩) 사용하면 Content-Length 사용하면 안됨

 

■ 콘텐츠 협상 (콘텐츠 네고시에이션)

 

클라이언트가 선호하는 표현 요청하면 서버가 그에 해당하는 표현으로 응답해줌

이러한 협상 헤더는 요청 시에만 사용한다.

 

 

Accept-Language 한국어로 요청하면, 다중 언어 지원하는 서버에서 한국어를 응답해준다. 

 

 

만약 다중 언어 지원 서버에 내가 원하는 게 없을 때 영어를 받고 싶다면 우선순위 설정이 필요하다. 

 

 

Quality Values(q) 값 사용하며 0~1 로 나타내고 클수록 높은 우선순위이다.

 

※ 참고

ko-KR : 한국사람이 쓰는 한국어

ko : 한국 공통어

 

실제 구글에서 선호하는 협상 내용

 

실제 구글에서도 한국어로 설정돼 있어서 한국어 우선순위가 높은 것을 볼 수 있다.

 

 

 

구체적인 것이 우선이다.

 

 

■ 전송 방식

1. 단순 전송 (Content-Length)

 

컨텐츠에 대한 길이를 알 때 사용

단순하게 요청하고 쭉 받는 것

 

2. 압축 전송 (Content-Encoding)

 

서버에서 gzip 으로 압축

클라이언트가 압축을 풀기 위해 Content-Encoding 정보 포함이 필요하다. 

 

3. 분할 전송 (Transfer-Encoding)

 

Transfer-Encoding : chunked(덩어리) -> 덩어리로 쪼개서 보낼 것이다.

분할 전송하면 오는대로 바로바로 표시 가능하다. 

분할 전송 시 Content-Length 사용하면 안됨 

 

* 이유

- Content-Length 처음에 예상 불가능

- chunked 마다 Content-Length 가 있음

 

4. 범위 전송 (Range, Content-Range)

 

이미지 절반 받다가 끊기면 끊겼던 부분부터 다시 받으면 된다. 

따라서 끊겼던 범위 지정해서 보내면 해당 부분 다시 돌려줘서 이전 부분 다운로드 없이 그 부분부터 진행하면 된다. 

 

■ HTTP 헤더 일반 정보 (정보성 헤더)

 

* From : 유저 에이전트의 이메일 정보

 

 

잘 사용하지 않음

검색 엔진에서 내 정보 크롤링 할 때 내 사이트 오지 말라고 할 때 연락할 수 있는 수단 중 하나

요청에서 사용

 

* Referer : 이전 웹 페이지 주소

 

 

많이 사용

현재 요청된 페이지 이전 웹 페이지 주소

Referer 를 사용해서 유입 경로 분석 가능

요청에서 사용

 

 

구글 페이지 -> 위키백과 들어왔을 때 Referer 이 구글 주소로 찍힌 것을 볼 수 있다. 

※ Referer 는 단어 referrer 의 오타이다. 

 

* User-Agent : 유저 에이전트 애플리케이션 정보

 

- 클라이언트 애플리케이션 정보(웹 브라우저 정보 등)

- 특정 브라우저에서만 문제만 생기는 것 -> 로그 보면 알 수 있다.

- 통계 정보 뽑기 쉽다

- 요청에서 사용

 

* Server : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보

 

HTTP 요청을 하면 중간에 여러 프록시 서버를 거친다. 

실제 진짜로 응답해주는 서버를 ORIGIN 서버(마지막 서버) 라고 한다. 

 

* Date : 메세지가 발생한 날짜와 시간

 

 

응답받은 날짜와 시간을 나타낸다. 

 

■ HTTP 헤더 특별한 정보

 

* Host : 요청한 호스트 정보(도메인)

 

- 요청에서 사용

- 필수값

- 하나의 서버가 여러 도메인을 처리해야 할 때

- 하나의 IP 주소에 여러 도메인이 적용되어 있을 때

 

 

가상 호스트를 통해 여러 도메인을 한 번에 처리할 수 있는 서버

실제 애플리케이션이 여러개 구동될 수도 있다.

 

 

 Host 정보를 통해 여러 도메인 중 올바르게 응답 처리를 할 수 있다. 

 

* Location : 페이지 리다이렉션

 

3xx 응답은 Location 위치로 자동 이동 (리다이렉트)

201 에서도 Location 값이 있는데 이는 생성된 리소스 URI 이다.

 

* Allow : 허용 가능한 HTTP 메서드

 

405 (Method Not Allowed) 에서 해당 메서드가 이용 불가하다는 것을 응답에 포함해야 함

많이 구현되어 있지 않음

 

* Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

 

 

503 (Service Unavailable) : 서비스 언제까지 불능인지 알려줄 수 있음

날짜 표기 또는 초단위 표기가 가능하다. 

잘 사용하지 않는다. 

 

■ 인증 헤더

 

* Authorization : 클라이언트 인증 정보를 서버에 전달

* WWW-Authenticate : 리소스 접근 시 필요한 인증 방법 정의

- 401 (Unauthorized) 응답과 함께 사용할 때 넣어줘야 함

 

■ 쿠키

 

 

 

쿠키를 미사용하면 로그인을 했음에도 welcome 페이지 접근 시 손님으로 인식한다. 

 

 

HTTP 는 무상태 프로토콜로 클라이언트 서버 요청 응답 주고 받으면 연결 끊어진다.

클라이언트가 다시 요청 시 서버는 이전 요청 기억하지 못한다.

클라이언트 서버는 서로 상태를 유지하지 않는 것이다. 

 

 

모든 요청에 사용자 정보를 포함되도록 개발해야 한다.

 

 

서버에서 Set-Cookie 로 홍길동이란 정보를 웹 브라우저의 쿠키 저장소에 저장한다. 

 

 

로그인 이후 welcome 페이지 접근하면 자동으로 웹 브라우저는 쿠키 저장소에서

Cookie 값을 찾아서 HTTP 헤더에 넣어서 서버에 보낸다. 

 

 

쿠키는 모든 요청에 쿠키 정보를 자동으로 포함한다.

 

 

모든 곳에 쿠키 보내면 보안에 취약하기 때문에 제약하는 방법이 있다. 

sessionid 만들고

expires 쿠키 만료 시간

path 에 해당하는 경로에 대해 허용

domain  해당 도메인에 대해서 쿠키 허용

secure 쿠키 보안 정보 

 

* session

사용처는 다음과 같다.

- 사용자 로그인 세션 관리

ex) 세션키를 만들어 db에 저장하고 세션 값을 클라이언트에 반환해준다.

클라이언트는 세션 id 를 보내게 되는 것이다. 

서버는 세션 id 있으면 사용자 정보 알 수 있다.

- 광고 정보 트래킹

 

쿠키 정보는 항상 서버에 전송된다.

- 네트워크 추가 트래픽 유발

- 최소한의 정보만 사용(세션 id, 인증 토큰)

- 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지(localStorage, sessionStorage) 참고

 

- 보안에 민감한 데이터는 저장하면 안된다. (주민번호, 신용카드 정보)

 

* 생명주기 (Expires)

 

- 만료일자 expires 로 GMT 시간으로 넣어줌

- 만료되면 쿠키 삭제

- max-age : 초 단위 설정 가능

- 0이나 음수 지정하면 쿠키 삭제됨

- 세션 쿠키 : 만료 날짜 생략하면 브라우저 종료시 까지만 유지

- 영속 쿠키 : 만료 날짜 입력하면 해당 날짜까지 유지

 

* 도메인 (Domain)

 

- 명시 : 명시한 문서 기준 도메인 + 서브 도메인 포함 접근 가능

- 생략 : 현재 문서 기준 도메인만 접근 가능

 

* 경로 (Path)

 

- 해당 경로를 포함한 하위 경로 페이지만 쿠키 접근

- 일반적으로 path=/ 루트로 지정

 

* 쿠키 보안 (Secure, HttpOnly, SameSite)

 

- Secure 적용하면 https 인 경우에만 쿠키 전송한다.

- httpOnly

1) XSS 공격 방지

2) 자바스크립트에서 접근 불가(document.cookie)

3) HTTP 전송에만 사용

- SameSite

1) XSRF 공격 방지

2) 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

※ 지원한 지 얼마 안돼서 SameSite 사용 시 브라우저에서 지원하는 지 확인하고 사용해야함

 

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

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