[HTTP] 7. HTTP 헤더1 - 일반 헤더🍪

안녕하세요!

벌써 섹션7이 되었습니다!!

그럼 시작해보도록 하겠습니다.

고고!!

1. HTTP 헤더 개요

1-1. HTTP 헤더

HTTP 헤더는 header-field = field-name ":" OWS field-value OWS (OWS: 띄어쓰기 허용) 이런 형식을 갖고 있습니다.

또한, field-name은 대소문자 구문이 없습니다.

HTTP 헤더의 특징에 관하여 설명하겠습니다.

HTTP 헤더는 시작라인 제외하고 HTTP 전송에 필요한 모든 부가 정보를 담고 있습니다.

예를 들어, 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등등 말이죠.

또한, HTTP 헤더는 표준 헤더가 굉장히 많습니다.

필요 시 임의의 헤더를 추가할 수도 있구요.

그럼 과거의 HTTP 헤더는 어땠을까요?

밑에서 설명하도록 하겠습니다.

1-2. RFC2616 (과거의 HTTP 헤더와 HTTP BODY)

우선, 과거의 HTTP 헤더를 분류해보도록 하겠습니다.

General 헤더: 메시지 전체에 적용되는 정보
- ex) Connection: close
Request 헤더: 요청 정보
- ex) User-Agent: Mozilla/5.0 (Macintosh; ..)
Response 헤더: 응답 정보
- ex) Server: Apache
Entity 헤더: 엔티티 바디 정보
- ex) Content-Type: text/html, Content-Length: 3423

과거의 HTTP BODY는 어땠을까요?

메시지 본문(message body)은 엔티티 본문(entity body)을 전달하는데 사용했습니다.

여기서 엔티티 본문은 요청이나 응답에서 전달할 실제 데이터가 들어있습니다.

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

어떤 정보를 제공했냐면...

데이터 유형(html, json), 데이터 길이, 압축 정보 등등이요!

그럼 이름이 왜 엔티티 헤더일까요?

말 그대로 엔티티와 관련이 있어서 엔티티 헤더에요~

그런데 HTTP 표준 스펙이 바뀌었습니다!!

1999년의 RFC2616은 폐기가 되고, 2014년에 RFC7230~7235가 등장했습니다.

1-3. RFC723x 변화 (현재의 HTTP 헤더와 HTTP BODY)

헤더에서 앤티티라는 말은 사라지고 표현(Representation)이라는 말로 바뀌었습니다.

여기서 표현은 표현 메타데이터(Representation Metadata)와 표현 데이터(Representation Data)가 합쳐진 것입니다.

최신 버전의 HTTP BODY를 한 번 봐볼까요?

페이로드(메시지 본문)을 통해 표현 데이터를 전달합니다.

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

표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공합니다. 엔티티 헤더처럼요!

어떤 정보를 제공했냐면...

데이터 유형(html, json), 데이터 길이, 압축 정보 등등이요!

그럼 표현에 관해서 자세히 살펴볼까요?

2. 표현

Content-Type: 표현 데이터의 형식 (html로 가는지 json으로 가는지... 알아야 해서)
Content-Encoding: 표현 데이터의 압축 방식
Content-Language: 표현 데이터의 자연 언어 (한국어인지 영어인지...)
Content-Length: 표현 데이터의 길이

표현 헤더는 전송과 응답 둘 다 사용합니다!

2-1. Content-Type

표현 데이터의 형식 설명

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423

<html>
<body>...</body>
</html>

HTTP/1.1 200 OK
Content-Type: application/json (기본으로 UTF-8)
Content-Length: 16

{"data":"hello"}

미디어 타입과 문자 인코딩 등 들어있습니다.

예를 들어...

text/html charset=utf-8
- html이면...
application/json
- json이면...
image/png

2-2. Content-Encoding

표현 데이터 인코딩

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Encoding: gzip
Content-Length: 521

wejflkewfjlwjflkwdjflkwjflksdjflknc,mvns,mnc23ur0892uroiwjflksndco2u8fujweklnclkwho3rujwlkewkmcl

표현 데이터를 압축하기 위해 사용합니다.

데이터를 전달하는 곳에서 압축 후 인코딩 헤더를 추가하고 (메시지 바디 있는 부분),

데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축을 해제합니다.

예를 들면 gzip, deflate, identity(압축 안하고 똑같이)가 있습니다.

2-3. Content-Language

표현 데이터의 자연 언어

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Language: ko
Content-Length: 521

<html>
안녕하세요.
</html>

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Language: en
Content-Length: 521

<html>
hello
</html>

표현 데이터의 자연 언어를 표현합니다.

예를 들면 ko, en, en-US 등 있습니다.

2-4. Content-Length

표현 데이터의 길이

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 5

hello

바이트(byte) 단위입니다.

중요한 점이 있는데 Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안 됩니다.

이유는 저 밑에서 설명하도록 하겠습니다.

3. 협상 (Contents Negotiation)

3-1. 협상이란...

클라이언트가 선호하는 표현 요청

클라이언트가 서버한테 원하는 표현을 해달라고 요청합니다.

그럼 서버가 최대한 맞춰줍니다. (서버가 못 맞춰줄 수도 있습니다.)

이 과정을 협상(Contents Negotiation)이라고 합니다.

Accept: 클라이언트가 선호하는 미디어 타입 전달
Accept-Charset: 클라이언트가 선호하는 문자 인코딩
Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
Accept-Language: 클라이언트가 선호하는 자연 언어

협상 헤더는 요청 시에만 사용합니다.

<Accept-Language 적용 전 (예시)>

예를 들어, 나는 한국어 브라우저를 사용합니다.

어떤 외국어 이벤트 페이지를 보고 들어가보고 싶다고 생각해서 들어갑니다.

이 페이지는 다중 언어를 지원하는 서버네요? 1순위는 영어이고, 한국어도 지원한다고 합니다.

근데, 클라이언트가 한국어를 원하는지 영어를 원하는지 서버한텐 정보가 없습니다.

그래서, 서버는 기본값인 영어로 클라이언트한테 응답을 합니다.

그럼 클라이언트는 영어가 나오니까 당황하고 쉽지 않아합니다.

이를 해결하기 위해 협상 (Contents Negotiation)을 합니다.

<Accept-Language 적용 후 (예시)>

내가 어떤 외국어 이벤트 페이지를 들어간 것과 그 페이지가 다중 언어(기본 영어, 한국어도 지원)를 지원하는 것까지는 똑같습니다.

이번엔 클라이언트가 서버한테 보낼 때 본인이 선호하는 언어는 한국어라고 보냅니다.

서버는 원래 기본 언어가 영어이지만, 한국어도 지원하기 때문에 Content-Language를 한국어로 하고, 한국어 메시지로 응답을 합니다.

이렇게 깔끔하게 해결이 되는 경우가 있지만,

사실 현실은 녹록 않죠~

밑에는 깔끔하게 떨어지지 않은 복잡한 예시입니다.

<Accept-Language 복잡한 예시>

과정은 다 똑같고 아까처럼 클라이언트가 한국어를 선호한다고 서버한테 전송합니다.

근데 이 서버는 다중 언어 지원 서버이지만, 기본 언어는 독일어이고 영어를 지원한다고 하네요?

그렇게 되면 서버는 한국어를 지원하지 않기 때문에 클라이언트한테 독일어로 보냅니다.

근데 솔직히 독일어로 오면 누구든 당황하지 않을까요? 그나마 영어가 나은데 왜 독일어냐거!!

그래서 우선순위를 둡니다.

우선순위에 관해서는 밑에서 설명하도록 하겠습니다.

3-2. 협상과 우선순위1 - 우선순위에 관하여

Quality Values(q) 값 사용

0에서 1까지 있으며, 숫자가 클 수록 높은 우선순위를 뜻합니다.

생략하면 우선순위는 1 입니다.

GET /event
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

예를 들어서 Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7가 있습니다.

여기에선 우선순위가 어떻게 될까요?

1순위는 q를 생략한 ko-KR이 되구요.

2순위는 그 다음 숫자가 높은 ko;q=0.9 입니다.

3순위는 en-US;q=0.8이고, 마지막으로 4순위는 en;q=0.7 입니다.

밑에서 예시를 자세히 봐보도록 하겠습니다.

<Accept-Language 복잡한 예시>

아까와 같은 상황에서 이번엔 클라이언트가 우선순위를 매겨서 서버한테 요청했습니다.

그러면 서버는 클라이언트가 보낸 우선순위를 확인하고 본인이 지원하는 언어 중에서 제일 우선순위가 높은 언어로 응답을 합니다.

(서버: 아~ 독일어보다 영어를 더 선호하는구나!)

3-3. 협상과 우선순위2 - 구체적인 것이 우선

구체적일수록 우선순위가 높습니다.

즉, 많이 디테일할수록 우선순위가 높습니다.

GET /event
Accept: text/*, text/plain, text/plain;format=flowed, */*

예를 들어서 Accept: text/*, text/plain, text/plain;format=flowed, */*가 있습니다.

1순위는 제일 디테일한 text/plain;format=flowed이고,

2순위는 그 다음으로 디테일한 text/plain 입니다.

3순위는 text/*이고, 4순위는 제일 간단한 */* 입니다.

3-4. 협상과 우선순위3 - 미디어 타입 맞추기

구체적인 것을 기준으로 미디어 타입을 맞춥니다.

Accept: text/*;q=0.3, text/plain;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5

4. 전송 방식

전송 방식은 총 4가지가 있습니다.

단순 전송
압축 전송
분할 전송 (쪼개서 전송)
범위 전송 (원하는 범위를 지정해서 전송)

4-1. 단순 전송

Content-Length

Content 길이를 알 수 있을 때 씁니다.

그냥 클라이언트가 한 번에 요청하면 서버가 단순하게 응답하는 형식입니다.

4-2. 압축 전송

Content-Encoding

클라이언트가 뭔가를 요청하면 서버에서 용량을 압축해서 클라이언트한테 전송합니다.

무조건 Content-Encoding을 넣어야 합니다.

4-3. 분할 전송

Transfer-Encoding

클라이언트에서 뭔가를 보내면 서버에서 분할해서 전송합니다.

즉, 서버에서 5 byte를 먼저 보내면 클라이언트에서 그 5 byte를 먼저 보고, 다음거 5 byte를 보내면 클라이언트가 그 다음거 5 byte를 보고 그런 형식입니다.

주로 용량이 클 때 사용합니다.

아까 위에서도 얘기했는데 분할 전송(Transfer-Encoding)에는 Content-Length를 넣으면 안 됩니다.

왜냐하면, Content-Length가 처음에는 예상이 안 되기 때문입니다.

또한, chunked마다 길이가 다 쓰여져 있기 때문입니다.

4-4. 범위 전송

Range, Content-Range

클라이언트가 범위를 정해서 서버한테 보내면 서버가 범위에 맞게 찾아서 전송합니다.

5. 일반 정보

일반 정보는 5가지로 분류했습니다.

From: 유저 에이전트의 이메일 정보
Referer: 이전 웹 페이지 주소
User-Agent: 유저 에이전트 애플리케이션 정보
Server: 요청을 처리하는 Origin 서버의 소프트웨어 정보
Date: 메시지가 생성된 날짜

5-1. From

유저 에이전트의 이메일 정보

From은 일반적으로 잘 사용되지는 않고, 사용한다면 주로 검색 엔진 같은 곳에서 사용합니다.

요청에서 사용합니다.

5-2. Referer

이전 웹 페이지 주소

현재 요청된 페이지의 이전 웹 페이지 주소로, 현재 많이 사용되고 있습니다.

A->B로 이동하는 경우, B를 요청할 때 Referer: A를 포함해서 요청을 해야 합니다.

또한, Referer를 사용해서 유입 경로 분석이 가능하며, 데이터 분석할 때 특히 많이 사용합니다.

From처럼 요청에서 사용합니다.

참고!! 원래 영어 단어로 따지면 referrer이 맞습니다. 근데 옛날에 오타로 쓰면서 이렇게 계속 쓰다보니 바꾸는게 더 힘들어져서 이렇게 referer 오타로 사용하게 되었습니다. (참고만 하고 알 필요는 X)

<예시>

1. 구글에서 hello 검색
2. 그냥 아무 페이지 들어감 (예를 들어 지식백과에 들어감)
3. 들어가서 오른쪽 클릭해서 쫘라락 자세히 나와있는 것 보다 보면 referer이 구글인 것을 알 수 있습니다.
=> 이전 페이지가 구글이었다는 것을 뜻합니다.

5-3. User-Agent

유저 에이전트 애플리케이션 정보

클라이언트의 애플리케이션 정보 겸 웹 브라우저 정보입니다.

사용자들이 어떤 브라우저에 많이 들어오는건지 파악 가능한 통계 정보로 쓰이기도 합니다.

또한, 로그를 피싱해보면 어떤 종류의 브라우저에서 장애가 발생하는지 파악할 수 있습니다.

From과 Referer처럼 요청에서 사용합니다.

<예시>
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36

5-4. Server

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

ORIGIN 서버란...

원래 http 요청을 보내면 중간에 여러 프록시 서버들을 거치게 됩니다.

그래서 실제 나의 요청이 도착해서 http 응답을 해주는 진짜 서버이자 마지막 서버입니다.

아까와 달리 응답에서 사용합니다.

<예시>

Server: Apache/2.2.22 (Debian)
server: nginx

5-5. Date

메시지가 발생한 날짜와 시간

<예시> Date: Mon, 21 May 2001 04:01:10 GMT
응답에서 사용합니다. (과거엔 요청에도 사용)

6. 특별한 정보

특별한 정보도 4가지로 분류해봤습니다.

Host: 요청한 호스트 정보(도메인)
Location: 페이지 리다이렉션
Allow: 허용 가능한 HTTP 메서드
Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

6-1. Host

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

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

요청에서 사용하며, 필수값입니다. 진짜 중요!!

하나의 서버가 여러 도메인을 처리해야 할 때 사용합니다.

즉, 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 사용합니다.

이게 무슨 말인지에 관해서는 밑에 그림을 통해 설명하도록 하겠습니다.

이 서버 안에 여러 개의 애플리케이션이 실제 다른 도메인으로 구동될 수 있습니다.

그런데 만약에 Host가 없으면 무슨 문제가 생길까요?

먼저 클라이언트가 /hello라고 요청을 보냅니다.

서버 입장에서는 /hello가 aaa.com과 관련된 애플리케이션에 들어가야할지 bbb.com에 관련된 애플리케이션에 들어가야할지 ccc.com에 관련된 애플리케이션에 들어가야할지 모릅니다 (구분 방법X).

왜냐하면 IP로만 통신하기 때문입니다.

초창기엔 이런 문제가 많아서 나중에는 Host는 무조건 넣어야돼!! 가 되었습니다.

위의 그림을 봐볼까요?

이번엔 Host를 넣었습니다.

클라이언트가 Host 헤더 필드를 넣어서 서버한테 전달하면 서버가 "아! 이건 aaa.com으로 들어가는구나!"하고 알아챕니다.

6-2. Location

페이지 리다이렉션

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동합니다.

이걸 리다이렉트라고 하고, 전 섹션 응답코드 3xx 부분에서 설명했었습니다.

201 (Created): Location 값은 요청에 의해 생성된 리소스 URI 입니다.
3xx (Redirection): Location 값은 요청을 자동으로 리다이렉션하기 위한 대상 리소스를 가리킵니다.

6-3. Allow

허용 가능한 HTTP 메서드

405 (Method Not Allowed)에서 응답에 포함해야 합니다.

만약에 URL 경로는 있는데 POST를 허용하지 않으면 405를 통해 알려줘야합니다.

"우리는 GET, HEAD, PUT만 허용 가능해!"

그런데 이건 실제로 서버에서 많이 구현하지는 않습니다.

6-4. Retry-After

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

503 (Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있습니다.
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT (날짜 표기)
Retry-After: 120 (초단위 표기)

사용하기에 쉽지 않습니다.

7. 인증 (Authorization)

Authorization 헤더: 클라이언트 인증 정보를 서버에 전달합니다.
- Authorization: Basic xxxxxxxxxxxxxxxxxxxx (인증과 관련된 값)
WWW-Authenticate: 리소스 접근 시 필요한 인증 방법을 정의합니다.
- 401 Unauthorized 응답과 함께 사용합니다. (401 오류 나면 이거 넣어줘야 함)
- WWW-Authenticate: Newauth realm="apps", type=1, title="Login to \"apps\"", Basic realm="simple"

8. 쿠키🍪

쿠키는 이렇게 2개의 헤더를 사용합니다.

Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)합니다.
Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청 시 서버로 전달합니다.

8-1. 쿠키 미사용 후 로그인 과정🍪

1. 처음 welcome 페이지에 접근 (로그인X)

사용자가 /welcome 페이지에 접근합니다.

그러면 서버에서 "안녕하세요. 손님"이라고 응답을 합니다.

2. 로그인

사용자가 POST로 유저 정보를 보내서 로그인을 합니다.

서버에서 "쏭쑤님이 로그인했습니다."로 응답을 합니다.

이렇게 되면 로그인이 된 html 화면이 나옵니다.

3. 로그인 이후 welcome 페이지에 접근

사용자는 쏭쑤라는 이름으로 로그인을 하고 다시 /welcome 페이지에 접근합니다.

그런데, 서버에서 로그인한 사용자인지 아닌지 구분을 못하네요..?

멍청이..

"안녕하세요. 쏭쑤"가 아닌 "안녕하세요. 손님"으로 응답을 합니다.

위의 예제에 대한 이유가 뭘까요?

그전에 배웠던 무상태 프로토콜 Stateless 기억나시나요?

http는 무상태 프로토콜 입니다.

그래서 요청 응답을 주고 받으면 연결이 끊어지고, 클라이언트가 다시 요청을 하면 서버는 이전 요청을 기억하지 못합니다.

이 이유 때문에 서버가 쏭쑤라는 이름을 기억하지 못하고 "안녕하세요. 손님"이라고 응답을 한 것입니다.

8-1(1). 대안🍪

위의 예제에 대한 대안이 있긴 합니다.

모든 요청에 사용자 정보를 포함하는 것인데요.

밑에 그림처럼 말이죠.

그런데 이 대안은 심각한 문제가 있습니다.

모든 요청과 링크에 사용자 정보를 다 포함..?

이렇게 모든 요청과 링크에 사용자 정보를 다 포함할 경우

보안에도 문제가 생기고 개발도 힘들어집니다.

개발자가 모든 요청에 사용자 정보를 일일이 다 넣어야 하니까죠~ 개고생입니다.

브라우저를 완전히 종료하고 다시 열면 어떻게 될까요?

요즘은 웹 스토리지가 있어서 거기에 저장을 하면 되긴 하지만...

개발자가 이걸 언제 다 개발하고 저장하고 일일이 다 할까요..?

옛날부터 이런 문제가 있어서 이를 해결하기 위해 쿠키🍪라는 개념을 도입했습니다.

8-2. 쿠키 사용 후 로그인 과정🍪

1. 로그인

사용자가 쏭쑤라는 이름으로 POST 메서드를 사용해서 로그인을 합니다.

서버는 쏭쑤라는 사용자의 정보를 쿠키에 넣습니다. (쿠키 헤더를 만들어서 응답합니다.)

그러면 웹 브라우저 내부에 쿠키 저장소가 있어서 그 저장소에 쏭쑤라는 사용자의 값을 저장합니다.

2. 로그인 이후 welcome 페이지 접근

사용자가 로그인을 하고 /welcome 페이지에 접근합니다.

웹 브라우저는 사용자가 서버한테 요청을 보낼 때마다 자동으로 쿠키를 뒤져서 쿠키값을 무조건 꺼내고 "Cookie: ~~" 헤더를 만들어서 서버한테 보냅니다.

그러면 서버는 쿠키를 열어서 사용자의 정보를 파악할 수 있게 됩니다.

<모든 요청에 쿠키 정보 자동 포함>

지정한 서버에 대해서는 웹 브라우저가 쿠키를 자동으로 뽑아내서 다 보내줍니다.

쿠키 매커니즘으로 다 해결이 된다는 것이죠.

그런데 이런식으로 사용자 정보를 다 보내면 보안에 문제가 생깁니다.

그래서 이것을 제약하는 방법이 있습니다.

8-3. 쿠키 제약하는 방법🍪

쿠키를 서버에서 세팅할 때
- ex) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure
사용처
- 사용자 로그인 세션 관리 (사용자 정보를 그대로 쿠키로 저장하는 것은 위험 -> 서버에서 세션 ID를 만들어 관리)
- 광고 정보 트래킹 (이 웹 브라우저 쓰는 사람이 이런 광고를 보는구나.. 하고 트래킹 할 때 사용)
쿠키 정보는 항상 서버에 전송됩니다.
- 단점: 네트워크 트래픽 추가 유발 (정보들을 계속 전송해서)
- 그래서.. 최소한의 정보만 사용합니다. (세션 id, 인증 토큰 정도)
- 또한, 서버에 전송하지 않고 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지를 사용합니다.
  (쿠키는 세팅하면 몇 개가 되든 계속 자동으로 전송이 되기 때문에 웹 스토리지도 이용해야 합니다.)
  (안 그러면 네트워크 부하가 심해질 수도..?ㄷㄷ)
주의할 점⚠️
- 보안에 민감한 데이터는 저장하면 안 됩니다. (주민번호, 신용카드 번호 등)

8-4. 쿠키 - 생명 주기🍪

Expires, max-age

위에 제약하는 방법에서 맨 첫 줄에 예시로 적은거 보이시나요?

거기에서 expires에 해당하는 부분에 관한 설명입니다.

쿠키를 무기한으로 보관할 수는 없기 때문에 있습니다.

Set-Cookie: expires=Sat, 26 Dec-2020 04:39:21 GMT (날짜 단위)
- 만료일이 되면 쿠키 삭제
Set-Cookie: max-age=3600 (3600초, 초단위)
- 0이나 음수를 지정하면 쿠키 삭제
세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지합니다.
- 전원을 껐다가 키면 로그인을 다시 해야하는 것..?
영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지합니다.

8-5. 쿠키 - 도메인🍪

Domain

쿠키가 아무 사이트 들어갈 때마다 생기면 큰일이 납니다. -> 도메인 지정 가능

ex) domain=example.org
명시: 명시한 문서 기준 도메인 + 서브 도메인 포함 다 전송합니다.
- ex) domain=example.org를 지정해서 쿠키 생성
  - example.org는 몰론이고, dev.example.org도 쿠키 접근
생략: 현재 문서 기준 도메인만 적용합니다.
- example.org에서 쿠키를 생성하고 domain 지정을 생략합니다.
  - example.org에서만 쿠키가 접근하고, dev.example.org는 쿠키가 접근하지 않습니다.
  - 즉, 하위 도메인에서는 접근하지 않습니다.

8-6. 쿠키 - 경로🍪

path

우선 도메인을 필터링하고, 그 다음에 경로로 필터링합니다.

ex) path=/home
이 경로를 포함한 하위 경로 페이지만 쿠키가 접근합니다.
일반적으로 path=/루트로 지정합니다.
ex) path=/home 지정할 경우
- /home -> 가능
- /home/level1 -> 가능
- /home/level1/level2 -> 가능
- /hello -> 불가능 (레벨이 맞지 않아서 쿠키가 전달되지 않습니다.)

8-7. 쿠키 - 보안🍪

Secure, HttpOnly, SameSite

Secure
- 쿠키는 http, https를 구분하지 않고 전송합니다.
- Secure를 적용하면 https인 경우에만 전송합니다.
HttpOnly
- XSS 공격을 방지합니다.
- 자바스크립트에서 접근 불가합니다.(document.cookie) (원래는 접근 가능합니다.)
- HTTP 전송에만 사용합니다.
SameSite
- XSRF 공격을 방지합니다.
- 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키를 전송합니다. (기능 적용된 지 몇 년 안 됨.)

섹션7이 끝이 났어여

생각보다 짤 많이 썼네용ㅋㅋㅋㅋㅋ

섹션8이 HTTP 마지막이랍니다~~

섹션8 다음엔 Spring 기본이 찾아올 예정👻

그럼 안뇽~~

'STUDY🍄' 카테고리의 다른 글

[Spring 기본] 1. 객체 지향 설계와 스프링 (2)	2025.03.19
[HTTP] 8. HTTP 헤더2 - 캐시와 조건부 요청 (1)	2025.03.13
[HTTP] 6. HTTP 상태 코드 (0)	2025.03.06
[HTTP] 5. HTTP 메서드 활용 (0)	2025.03.03
[HTTP] 4. HTTP 메서드 (0)	2025.03.02

1. HTTP 헤더 개요

1-1. HTTP 헤더

1-2. RFC2616 (과거의 HTTP 헤더와 HTTP BODY)

1-3. RFC723x 변화 (현재의 HTTP 헤더와 HTTP BODY)

2. 표현

2-1. Content-Type

2-2. Content-Encoding

2-3. Content-Language

2-4. Content-Length

3. 협상 (Contents Negotiation)

3-1. 협상이란...

3-2. 협상과 우선순위1 - 우선순위에 관하여

3-3. 협상과 우선순위2 - 구체적인 것이 우선

3-4. 협상과 우선순위3 - 미디어 타입 맞추기

4. 전송 방식

4-1. 단순 전송

4-2. 압축 전송

4-3. 분할 전송

4-4. 범위 전송

5. 일반 정보

5-1. From

5-2. Referer

5-3. User-Agent

5-4. Server

5-5. Date

6. 특별한 정보

6-1. Host

6-2. Location

6-3. Allow

6-4. Retry-After

7. 인증 (Authorization)

8. 쿠키🍪

8-1. 쿠키 미사용 후 로그인 과정🍪

8-1(1). 대안🍪

8-2. 쿠키 사용 후 로그인 과정🍪

8-3. 쿠키 제약하는 방법🍪

8-4. 쿠키 - 생명 주기🍪

8-5. 쿠키 - 도메인🍪

8-6. 쿠키 - 경로🍪

8-7. 쿠키 - 보안🍪

'STUDY🍄' 카테고리의 다른 글

티스토리툴바