-
8. HTTP 헤더 (1)HTTP 2022. 8. 1. 17:12
HTTP 헤더
Request Message Response Message GET /search?q=hi&hl=ko HTTP/1.1
Host: www.google.comHTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423
<html>
<body>...</body>
</html>위의 빨간 글씨가 HTTP의 헤더이다. 헤더에는 HTTP 전송에 필요한 모든 부가 정보가 포함된다.
ex) Message body 내용, 크기, 압축, 인증 등
● RFC2616(과거)
과거에는 헤더를 아래와 같이 4가지로 분류했다.
• 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
과거에는 Message body가 Entity body를 전달하기 위해 사용되었다.
따라서, Entity 헤더에서 Entity body의 데이터 유형, 길이 등의 정보를 제공하였다.
그러나, 2014년 RFC7230 ~ 7235가 등장하게 되면서, RFC2616이 사라지게 된다.
● RFC723x
기존 RFC2616에서 RFC723x로 변하면서, Entity라는 단어는 Representation으로 대체되었다.
Representation은 Representation Metadata + Representation data로 구성되어 있다.
Representation은 요청이나 응답에서 전달할 데이터라고 생각하면 된다.
RFC723x로 넘어오면서 Message Body를 통해 Representation data인 실제 전달하고자 하는 데이터를 전달한다.
또한, 이 데이터의 타입(Representation Metadata)과 같은 정보를 헤더를 통해 제공하게 되었다.
표현 헤더
표현 헤더에는 Message Body에 존재하는 표현 데이터의 추가 정보를 포함하고 있다.
• Content-Type: 표현 데이터의 형식
미디어 타입, 문자 인코딩을 전달
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423
<html>
<body>...</body>
</html>• Content-Encoding: 표현 데이터의 압축 방식
표현 데이터를 압축하기 위해 사용하며, 데이터를 전달하는 쪽에서 압축 한 뒤, 인코딩 헤더를 추가한다.
당연하게도, 전달 받는 쪽에서는 인코딩 헤더 정보로 압축을 해제한다.
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Encoding: gzip
Content-Length: 521
lkj123kljoiasudlkjaweioluywlnfdo912u34lj
ko98udjkl• Content-Language: 표현 데이터의 자연 언어
표현 데이터의 자연 언어를 표현한다. (한국어, 영어 등)
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Language: ko
Content-Length: 521
<html>
안녕하세요.
</html>
• Content-Length: 표현 데이터의 길이데이터의 길이는 바이트 단위로 계산된다.
※ Transfer-Encoding (전송 코딩)을 사용하면, Content-Length를 사용하면 안 된다.
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 5
hello이러한 표현 헤더는 Request, Response Message 모두 사용한다.
협상 헤더(Content Negotiation)
클라이언트가 서버에 요청시, 선호하는 표현 타입을 말한다.
서버에서는 클라이언트가 선호하는 표현에 맞게 응답 메세지로 보내준다.
※ 항상 요청대로 응답되는 것은 아님
● Accept: 클라이언트가 선호하는 미디어 타입 전달
● Accept-Charset: 클라이언트가 선호하는 문자 인코딩
● Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
● Accept-Language: 클라이언트가 선호하는 자연 언어예를 들어, 1순위로 영어, 2순위로 한글을 지원하는 서버에 클라이언트가 특정 데이터를 요청할 때, Accept-Language를 설정하지 않으면 표현 데이터가 영어로 오게 된다.
만약, "Accept-Language: ko"를 헤더에 넣고 요청하게 되면 서버에서는 이를 확인하여, 표현 데이터가 한글로 오게 된다.
그렇다면, 한글을 지원하지 않는 서버에서는 어떻게 동작하게 될까 ?
서버에서 제공하는 언어 중, 1순위 언어로 응답 메세지가 오게 된다.
이를 해결하기 위해, 협상 헤더에 Quality Values를 통해 표현 데이터 타입의 우선순위를 설정하여 보내면 된다.
● 우선순위
Quality Values(q)값을 사용하여, 우선순위에 맞게 표현 타입을 받을 수 있다.
0~1, 사이의 값을 사용하며 숫자가 클 수록 우선순위가 높다.
Quality Values를 생략하면 1로 설정된다.
"Accept-Language: ko-KR,ko:q=0.9,en-US;q=0.8,en;q=0.7"를 표현 헤더에 넣어 요청하면,
1.ko-KR
2.ko
3.en-US
4.en
의 우선순위로 서버에서 표현 데이터 타입에 맞게 응답 메세지를 보내준다.
이러한 우선순위는 Accept-Language뿐만 아니라, 다른 항목에도 적용된다.
"Accept: text/*, text/plain, text/plain;format=flowed, */*"를 표현 헤더에 넣어 요청하면,
Quality Values를 적용할수도 있지만, 생략할 경우 구체적인 것을 우선으로 하여 응답 메세지를 보내준다.
1. text/plain;format=flowed
2. text/plain
3. text/*
4. */*의 우선순위로 서버에서 매칭하여 응답 메세지를 보내준다.
Quality Values를 다음과 같이 적용해보자.
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,text/html;level=2;q=0.4, */*;q=0.5
Accept-Language에서와 마찬가지로, 각 미디어 타입에 맞춰 우선순위를 따로 설정해줄 수 있다.
전송 방식
● 단순 전송 (Content-Length)
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423
<html>
<body>...</body>
</html>위와 같이, 단순히 Content-Length를 통해 정보를 넘겨주어 Response Message를 전송하는 것을 말한다.
● 압축 전송 (Content-Encoding)
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Encoding: gzip
Content-Length: 521
lkj123kljoiasudlkjaweioluywlnfdo912u34ljko98udjklMessage Body를 압축하여, 단순 전송보다 짧은 Content-Length로 Response Message를 전송하는 것을 말한다.
전송하는 데이터의 크기는 줄어들 수 있지만, 클라이언트에서 압축을 해제해야한다.
● 분할 전송 (Transfer-Encoding)
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
5
Hello
5
World
0
\r\nMessage Body를 덩어리로 나누어 전송하는 것을 말한다.
이 때, HTTP 헤더에 Content-Length를 포함하면 안 된다. (예측이 불가능함)
주로, 데이터의 크기가 큰 경우 사용한다.
압축 하여 보낼 경우, 해당 데이터를 받아서 압축 해제를 하여 클라이언트에서 작업을 진행할 수 있지만,
분할 전송의 경우 덩어리로 나누어진 데이터가 도착할 때마다 작업을 진행할 수 있다.
● 범위 전송 (Range, Content-Range)
Request Message Response Message GET /event
Range: bytes=1001-2000HTTP/1.1 200 OK
Content-Type: text/plain
Content-Range: bytes 1001-2000 / 2000
qweqwe1l2iu3019u2oehj1987askjh3q98y특정 데이터를 전달받는 과정에서 연결이 끊어진 경우, 해당 데이터를 처음부터 전송 받는 것은 비효율적이다.
따라서, 클라이언트에서 범위(Range)를 설정하여 요청하면, 이에 해당하는 데이터를 효율적으로 전송할 수 있게 된다.
정보
● 일반 정보
● Referer : 이전 웹 페이지 주소 (Request에서 사용)
특정 웹 페이지에 접속하였을 때, 이전 웹 페이지 주소를 말한다.
예를 들어, 구글 검색을 통해 A라는 웹 사이트에 접속했다고 가정해보자.
해당 웹 사이트에 Request Message를 보낼 때, "referer: www.gogle.com"이 포함되어 전송된다.
referer를 통해, 유입 경로를 분석하는데 사용할 수 있다.
● User-Agent : 유저 에이전트 애플리케이션 정보 (Request에서 사용)사용자가 사용하고 있는 애플리케이션의 정보(웹 브라우저 종류 등)을 Request Message에 포함하여 전송한다.
이는 통계를 내는데 사용되기도 하며, 서버에서 특정 애플리케이션에서만 발생하는 오류를 파악하는데 도움을 준다.
● Server : 요청을 처리하는 Origin 서버의 소프트웨어 정보 (Response에서 사용)
HTTP 요청을 보내면, 여러 프록시를 거쳐 실제 Response Message를 전송해주는 서버에 도착한다.
이 Server 헤더에는 실제 메세지를 전송해주는 Origin 서버의 소프트웨어 정보를 포함하여 전송된다.
● Date : 메시지가 생성된 날짜 (Response에서 사용)Response Message가 생성된 날짜를 의미한다.
● 특별한 정보
● Host : 요청한 호스트 정보(도메인) (Request에서 사용)
가상호스트를 통해, 하나의 IP 주소에서 여러개의 도메인을 처리하고 있는 서버가 있다고 가정해보자.
만약, 특정 클라이언트에서 Request Message가 왔을 때, 메세지에 해당하는 요청을 어떤 도메인에서 처리해야하는지 불분명할 수 있다. 따라서, 요청한 도메인의 정보를 포함하여 전달함으로써 이러한 문제를 방지할 수 있다.
필수로 포함되어야하는 항목
● Location : 페이지 리다이렉션 (Response에서 사용)웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, 해당 Location 위치로 자동 이동(Redirect)된다.
201 (Created) 응답의 결과에 존재하는 Location 헤더는 요청에 의해 생성된 Resource의 URI를 의미한다.
● Allow : 허용 가능한 HTTP 메서드 (Response에서 사용)
405 (Method Not Allowed) 상태 코드의 응답에서 포함하는 헤더로써, 허용 가능한 HTTP의 메서드를 가리킨다.
● Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간 (Response에서 사용)
서버 점검 등으로 이용이 불가능할 때, 언제까지 기다려야 하는지를 나타내주며 날짜 혹은 초단위로 표기할 수 있다.
● Authorization : 클라이언트 인증 정보를 서버에 전달
인증에 필요한 정보를 서버에 전송할 때 사용하는 헤더로써, 인증 방식에 따라 전달되는 값이 다르다.
● WWW-Authenticate : 리소스 접근시 필요한 인증 방법 정의
401 (Unauthorized) 상태 코드의 응답에서 포함하는 헤더로써, Resource에 접근시 필요한 인증 방법을 알려준다.
쿠키 (Cookie)
서버에서 클라이언트로 전달하는 "Set-Cookie"와 이를 저장하여, HTTP 요청시 서버로 전달하는 "Cookie"가 존재한다.
앞서, HTTP는 무상태(Stateless) 프로토콜인 것을 배웠다.즉, 서버와 클라이언트는 서로의 상태를 유지하지 않기 때문에, Login과 같은 기능이 정상적으로 동작하지 않을 수 있다.이를 해결하는 방법이 바로 Cookie이다.
예를 들어, 클라이언트에서 특정 웹 사이트에 Login을 하게 되면, 서버에서는 Response Message에 Set-Cookie로 쿠키 정보를 전송한다. 클라이언트에서는 이를 쿠키 저장소에 저장하여, 해당 웹 사이트에 접근할 때 마다 쿠키 저장소에서 쿠키를 조회하여 Request Message에 포함하여 전송한다.
ex) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec 2020 00:00:00 GMT; path=/; domain=.google.com; Secure
● sessionId : 서버에서는 Login 등의 요청이 들어오면, 이에 해당하는 Session Id를 생성하여 전송한다. (ID / PW 정보를 쿠키로 사용하면 보안상의 문제가 있으므로)
이렇게 생성된 sessionId를 통해, 쿠키로써 사용을 하게되는데 해당 쿠키 정보는 클라이언트에서 서버로 요청을 보낼 때마다 함께 전송이 된다. 따라서, 네트워크 트래픽 부하가 발생할 수 있으므로 최소한의 정보만 쿠키로 사용한다.
● Expires, max-age : 생명주기를 의미하며, expires를 사용하여 만료일을 설정하거나, max-age를 사용하여 초 단위로 생명 주기를 설정할 수 있다.
이때, 만료 날짜를 입력하면 해당 날짜까지 유지되는 "영속 쿠키"와 날짜를 생략하면 웹 브라우저 종료시까지 유지되는 "세션 쿠키"가 존재한다.
● Domain : Domain을 명시할 경우, 해당 도메인 + 서브 도메인을 포함하여 쿠키를 사용할 수 있게 된다.
만약, Domain을 생략할 경우, 현재 문서 기준 도메인에만 쿠키가 적용 된다.
● Path : path로 설정한 경로를 포함한 하위 경로 페이지에만 접근이 가능하다.
일반적으로는, "path=/;"와 같이 Root로 지정을 한다.
만약, "path=/home"으로 지정한 경우, "/home", "/home/level1" 등에는 접근이 가능하지만 "/hello" 에는 접근이 불가능 하다.
● 보안 (Secure, HttpOnly, SameSite)
1. Secure
일반적으로 쿠키는 Http, Https를 구분하지 않고 전송한다. 만약 Secure라는 키워드를 포함하면, Https인 경우에만 쿠키를 전송한다.
2. HttpOnly
XSS(Cross Site Scripting)공격을 막기 위한 방법으로, 자바 스크립트에서 쿠키에 접근이 불가능해진다.
또한, HTTP에서만 쿠키를 전송할 수 있게 된다.
3. SameSite
XSRF 혹은 CSRF(Cross-Site Request Forgery)공격을 막기 위한 방법으로, Request 도메인과 쿠키의 도메인이 같은 경우에만 쿠키를 전송할 수 있게 된다.
'HTTP' 카테고리의 다른 글
9. HTTP 헤더 (2) (0) 2022.08.01 7. HTTP 상태코드 (0) 2022.07.28 6. HTTP 메서드 활용 (2) (0) 2022.07.28 5. HTTP 메서드 활용 (1) (0) 2022.07.28 4. HTTP 메서드 (0) 2022.07.28