녕의 학습 기록
[HTTP] HTTP 헤더 (2) 본문
♪ 학습 내용
전송 방식에 따른 헤더, 일반/특수 정보를 담은 헤더, 쿠키
* 전송방식에 따른 HTTP 헤더
HTTP 메시지 바디 내 데이터의 전송 방식은 여러 가지가 있다.
그리고 이 전송 방식 정보를 담는 헤더들도 여러가지이다.
- 단순 전송
단순 전송 시에 메시지 바디 내 데이터의 길이를 Content-length 헤더로 넘겨준다.
- 압축 전송
압축 전송 시에 압축 형식에 대한 정보를 Content-Encoding 헤더로 넘겨준다.
- 분할 전송
" Transfer-Enconding: chunked "
chunked -> 덩어리로 쪼개
분할 전송시에는 content-length 헤더가 없다.
왜? 예상이 가지도 않고, chunck 마다 안에 길이 정보가 포함되어있기 때문.
- 범위 전송
서버에 데이터를 요청할 때 전부 다가 아닌, 일정 범위만 지정하여 요청.
Content-Range
* 일반 정보를 담는 HTTP 헤더
- From
유저 에이전트의 이메일 정보. 잘 사용하지 않는다.
요청에서 사용
- Referer
이전에 있던 웹 페이지의 주소에 대한 정보이다.
A에 있다가 B 웹페이지를 요청한 경우에는 Referer: A를 포함.
이를 통해서 어디서 들어왔는지 유입 경로 분석이 가능하다
요청에서 사용
- User-Agent
클라이언트의 애플리케이션 정보를 포함한다(웹브라우저 등등)
이를 이용해 특정 브라우저에서 버그 발생 시 어떤 브라우저에서 장애가 발생하는지 파악 가능
요청에서 사용
- Server
클라이언트가 요청을 하면 많은 프록시 서버를 거치는데 그 중 가장 마지막 서버,
즉 요청을 처리하는 ORIGIN 서버의 sw정보를 포함한다.
응답에서 사용
- Date
메시지가 발생한 날짜와 시간을 GMT 시간으로 알려준다.
응답에서 사용
* 특별한 정보를 담는 HTTP 헤더
위의 일반적인 정보와는 다르게 실제 애플리케이션 구동에 영향을 주는 헤더들이 있다.
- Host
필수 헤더로, 요청한 호스트의 정보(도메인)를 담고 있다.
가상 호스트를 통해 하나의 서버가 여러 도메인을 한번에 처리할 수 있는데,
이때 Host 헤더 없이 그냥 서버로 요청을 보내면 서버 입장에서는 요청이 어떤 것과 관련된 건지 알 수 없다.
(port 같은)
Host 헤더를 사용하면 해결 가능!
- Location
앞에 3XX HTTP 상태코드에서 Location 헤더가 있으면 Location 위치로 리다이렉트 한다는 것을 학습했다.
3XX대에서는 리다이렉트 경로.
201(Created) 상태 코드에서 Location 헤드는 새로 생성된 리소스의 URI 이기도 하다.
- Allow
요청의 URI 경로는 있는데, 요청 메서드 사용이 불가능 한 경우 405 응답에서 포함.
허용 가능한 HTTP 메서드에 관한 정보를 포함하고 있다.
- Retry-After
유저가 다음 요청을 하기까지 기다려야 하는 시간이다.(like 503 서비스가 언제까지 불능인지)
날짜를 표기하거나, 초단위를 표기하거나 두가지로 시간을 안내한다.
* 인증 HTTP 헤더
- Authorization
클라이언트의 인증 정보를 서버에 전달한다.
인증마다 value에 값이 다르다.
- WWW-Authenticate
401 응답(인증, 접근에 문제가 있을 때)에서 리소스 접근 시에 필요한 인증 방법을 정의해준다.
이러이러한 정보를 참고해서 다시 인증해~~
* 쿠키
앞에서 학습한 HTTP의 Stateless 특성 (무상태. 연결이 끊어진다. 상태를 유지하지 않는다.)
으로 인해 필요한 개념이 바로 쿠키이다.
주로 사용자의 로그인 세션 관리에서 많이 사용한다.
예를 들면, 클라이언트가 POST 메서드의 HTTP 요청 메시지로 서버에 로그인을 했다고 치자.
그리고 다시 서버에 요청을 하면?
서버 입장에서는 이 요청이 누구로부터 온 것인지 구분 불가.
왜? 서버는 이전 요청을 기억하지 않기 때문이다(Stateless).
앞에서 학습했던 것처럼 이를 해결하자고 하면 모든 요청마다 사용자의 정보를 포함해야한다.
이건 당연히 여러 방면으로 힘들다.
하지만 쿠키를 사용하면 쉽게 해결된다.
쿠키 사용 시 내가 로그인 하면 응답의 Set-Cookie 헤더를 통해 쿠키를 전달한다.
그리고 이 쿠키를 받은 클라쪽에서는 쿠키를 쿠키 저장소에 저장한다.
그 후로는 요청 보낼때마다 자동으로 쿠키 저장소를 뒤지고, 값을 꺼내어 Cookie 헤더를 통해 요청에 포함한다.
근데 이 경우에도 마찬가지로 모든 요청에 쿠키 정보가 자동으로 포함된다.
보안에 문제가 생길 수도??
이를 보완하기 위해 쿠키 헤더에 여러 옵션을 줄 수 있다.
- sessionId
전에는 실제 데이터를 쿠키로 클라이언트에게 주었지만, 이 sessionId에 로그인 정보를 저장하고
클라이언트에게 이 sessionId를 응답으로 넘겨준다.
그렇게 되면 클라이언트는 이 sessionId만을 가지고 로그인 정보를 유지할 수 있다.
- Expires / max-age
또한 쿠키에게 생명주기를 부여할 수도 있다.
expires : GMT 기준 만료일이 되면 쿠키 삭제
max-age : 0이나 음수 지정 -> 쿠키 삭제
평소에 웹페이지 이용하다 보면 브라우저를 껐다 켜도 로그인이 유지되는 페이지가 있었다.
이 경우는 만료 날짜를 입력하여 해당 날짜까지 쿠키를 유지한 경우.
이를 영속 쿠키 라고 한다.
반면에 만료 날짜를 생략하면 브라우저 종료 때 까지만 로그인이 유지된다.
이를 세션 쿠키 라고 한다.
- Domain
domain을 통해 특정 도메인을 지정하면, 해당 도메인과 그 서브 도메인만이 쿠키에 접근이 가능!
(쿠키에 접근이 가능하다 == 클라이언트 요청 시에 쿠키가 같이 전송)
만약 생략한다면 현재 문서 기준 도메인만 적용된다.(하위는 불가)
- Path
path=/home 이라 지정하면 이 경로를 포함한 그 하위 경로 페이지만 쿠키에 접근할 수 있다.
즉, 도메인 안의 경로를 추가로 필터링하는 것.
보통은 한 도메인 안에서는 전부 쿠키에 접근하는게 일반적이라 " path=/ " 로 지정한다.
- Secure
쿠키는 http나 https를 구분하지 않고 전부 전송한다.
하지만 Secure를 적용하면 https 인 경우에만 서버로 쿠키를 전송한다.
보안..!
- HttpOnly
자바스크립트에서 쿠키 접근하지 못하게 한다.
보안..!
- SameSite
요청한 도메인과 쿠키에 설정된 도메인이 같은 경우에만!! 쿠키를 전송한다.
보안..!
기본적으로 쿠키 정보는 항상 서버에 전송되므로 최소한의 정보만을 사용해야 한다.
그리고 보안에 민감한 데이터(주민번호 등)는 쿠키로 저장하면 안된다. 당연하게도.
♪ 다음 학습 내용
캐시와 조건부 요청
모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의
실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...
www.inflearn.com
'Dev > HTTP' 카테고리의 다른 글
| [HTTP] HTTP 헤더 (3) (0) | 2023.01.03 |
|---|---|
| [HTTP] HTTP 헤더 (1) (1) | 2022.12.29 |
| [HTTP] HTTP 상태코드 (0) | 2022.12.27 |
| [HTTP] HTTP 메서드 활용 (0) | 2022.12.25 |
| [HTTP] HTTP 메서드 (0) | 2022.12.25 |
