Frontend Study - 1/HTTP

주요 HTTP headers에 대하여 !

갓데미 2023. 2. 23. 19:42

HTTP headers는 클라이언트 - 서버 요청/응답 간에 부가적인 정보를 전송할 수 있게 해준다. 

종류가 꽤나 많은데 그 중 자주 사용되고 중요해 보이는 것들 위주로 알아 보려한다.

 

 

목차 

1. HTTP headers의 분류

2. HTTP headers 살펴보기

  - General headers

  - Request headers

  - Response headers

  - Payload headers (Entity headers)

 

 

1. HTTP headers의 분류

 

http헤더는 두가지 방법으로 그룹화 할 수 있다.

 

첫째로 컨텍스트에 따라 네가지로 나뉜다. 

- General header : 요청과 응답 모두에 적용되지만, 최종적으로 바디에서 전송되는 데이터와는 관련이 없음

- Request header : fetch될 리소스나 클라이언트 자체에 대한 정보를 포함

- Response header : 위치나 서버 자체에 대한 정보와 같이 응답에 대한 정보를 포함

- Entity header : 컨텐츠의 길이나 타입과 같이 entity 바디에 대한 정보를 포함

 

 

두번째로 프록시 처리 방법에 따라 두가지로 나뉠 수 있다. 

- End-to-end headers : 이 헤더의 경우 반드시 마지막 수령인에게까지 전송되어야 한다. 요청의 경우 서버에게, 응답의 경우 클라이언트에게 반드시 전송되어야 하는 것. 중간 프록시 들은 이 end-to-end headers를 수정하지 않고 그대로 재전송 해야 하며, 캐시는 이것을 반드시 저장해야 한다. 

 

- hob-by-hob headers : 이 헤더의 경우는 단일 전송-레벨 연결에서만 의미가 있고, 프록시에 의해 재전송되거나 캐시되어선 안된다. 홉간 헤더에는 Connection, keep-alive, proxy-authenticate와 같은 헤더들이 있고 Connection 일반 헤더(general header)를 사용해 설정할 수 있다.

 

 

첫번째 방법인 컨텍스트에 따라 나뉜 4가지 분류를 통해 각각의 headers를 살펴보려고 한다.

 

2. HTTP headers 살펴보기

 

1) General header (공통 헤더)

 

- Date 

HTTP메시지가 만들어진 날짜와 시간을 포함하고, *forbidden header name이다.

 

 

* forbidden header name은 프로그래밍 방식으로 수정할 수 없다. 프로그래밍 방식으로 수정할 수 없다는 것은 해당 headers를 웹 개발자가 자바스크립트나 다른 프로그래밍 언어를 통해 임의로 변경할 수 없다는 의미이다. 이러한 제한은 보안 취약점을 방지하고 사용자의 개인 정보 보호를 위한 것이다. user agent(일반적으로 브라우저)가 해당 헤더에 대하여 모든 관리 권한을 가진다. 아래와 같은 요소들이 forbidden header로 분류된다.

 

//forbidden headers

Accept-Charset, Accept-Encoding
Access-Control-Request-Headers, Access-Control-Request-Method
Connection, Content-Length
Cookie, Date, DNT, Expect
Host, Keep-Alive, Origin, Permissions-Policy
Proxy-, Sec-, Referer, TE, Trailer, Transfer-Encoding
Upgrade, Via

 

 

- Cache-Control

요청과 응답 내의 캐싱을 제어하는 directives(지시문)을 지정하기 위해 사용된다.

이 지시문은 브라우저, 공유된 캐시(예: 프록시, CDNs)에서 캐싱을 제어한다.

 

 

* 요청 지시문의 종류

* max-age=<seconds>
: 리소스가 fresh(신선한 상태)라고 판단할 최대 시간 지정. 
: 응답이 수신된 이후 경과된 시간이 아니라, 원본 서버에서 응답이 생성된 이후 경과된 시간이다.
: 응답이 생성되고 지정된 시간이 지나면 해당 응답을 재사용하지 못하게 된다. 
: 예전 HTTP(HTTP/1.0)에서는 no-cache를 지원하지 않기 때문에 max-age=0으로 지정하여 리로딩을 위해 사용하였다.
: 최근 브라우저들도 여전히 리로딩을 위해 max-age=0을 사용하곤 한다.
: 값이 음수나 그 외 정수가 아닌 경우, 캐싱 동작은 정의되지 않다.


* no-cache
: 캐시가 응답을 재사용하기 전에, 서버에 유효성 검사하도록 요청하는데 사용된다.
: no-cache라면 응답이 최신 상태 더라도 서버로부터 응답을 재검증 해야 하고, 더 최신 버전의 응답을 요청할 수 있게 한다. 
: 강제 리로딩을 위해 사용되곤 한다.


* no-transform
: 응답에 대해 변형이나 변환이 일어나지 못하게 한다. 
: 일부 중간단계(구글 웹 라이트, 프록시..)에서 캐시공간 절약, 트래픽량을 줄이기 위해 이미지 포맷을 변환하는데, 이것을 막는다.


* only-if-cached
: 새로운 데이터를 받지 않는 것.
: 오로지 캐시된 데이터만 응답받고 최신 데이터를 위한 요청을 서버에 보내지 않게 한다.
 
 
 
* 응답 지시문의 종류
 
* must-revalidate
: 상태가 stale한 경우에는 반드시 원 서버에 검증을 받아야 한다는 것
: 보통 must-revalidate은 max-age와 함께 쓰인다. 
: ex) Cache-Control: max-age=604800, must-revalidate
: 이것의 의미는 지정 시간 이전에는 재사용하지만 지정시간이 지나면 반드시! 재검증을 받아야 한다는 것
: HTTP는 원 서버와 연결이 끊겼을 때 캐시의 stale한 응답을 재사용할 수 있게 하는데 이를 막을 수 있게 된다.


* no-cache
: "캐시하지 말라"라는 뜻이 아니다. 응답을 캐시할 수 있지만 재사용 전에 검증하라는 것
: 캐시가 원 서버와 연결이 끊어져 있더라도 캐시는 원 서버 검증해야 한다는 것
: 응답을 캐시에 저장할 수 있다. 저장하는 것 자체를 원하지 않으면 아래 no-store을 이용하면 된다.
: 캐시의 컨텐츠를 항상 업데이트 하도록 하려면 이 지시문을 사용하면 된다.


* no-store
: 어떤 캐시든간에 저장하지 마라 라는 뜻.


* no-transform
: 요청의 no-transform 과 동일


* public
: 응답이 공유 캐시에 저장될 수 있음을 나타낸다.
: 일반적으로 페이지가 Basic Auth나 Digest Auth로 보호되어 있으면 Authorization 헤더와 함께 요청을 보낸다.
: Authorization 헤더 필드를 가진 요청에 대한 응답은 근본적으로 공유 캐시로 캐시할 수 없다.
: 이러한 제한을 public을 통해서 풀 수 있다. 


* private
: 위의 public과 다르게 응답이 단일 사용자를 위한 것이며, 공유 캐시에 저장되지 않아야 한다는 의미.
: 로그인 이후의 응답이나 쿠키를 통해 관리되는 세션들에 private 지시문을 넣어 주어야한다.
: 만약 개인적인 응답 데이터에 private을 지정하지 않는다면 공유 캐시에 저장되어 많은 사람들에게 유출될 수 있다.


* proxy-revalidate
: must-revalidate과 동일하지만 프록시와 같은 공유 캐시에만 적용되며 사설 캐시에 의해서는 무시된다.


* max-age=<seconds>
: 응답이 생성되고 얼마의 시간 만큼 신선한 상태로 정의할 것인지.


* s-maxage=<seconds>
: max-age 혹은 Expires 헤더의 재정의. 프록시와 같은 공유 캐시에만 적용되며 사설 캐시에서는 무시.

 

 

- Connection

현재 전송이 완료된 후, 네트워크 접속을 유지할 지 말지 제어한다.

keep-alive라면 연결은 지속되고, 지속된 연결을 통해 동일한 서버에 대한 후속 요청을 할 수 있다. 

Connection: keep-alive
Connection: close

HTTP/1.0의 경우 close가 기본값, HTTP/1.1의 경우 keep-alive가 기본 값이다.

 

Connection과 Keep-alive 같은 연결-지정(Connection-specific) 헤더들은 HTTP/2.0에서 금지되었다.

HTTP/2.0에서 Connection header를 사용할 때, 크롬, 파이어폭스는 그냥 무시만 하지만 사파리의 경우 해당 필드가 포함된 응답은 처리하지 않아 버린다.

 

 

 

2) Request header (요청 헤더)

 

- Host : 요청을 하는 서버의 host와 port넘버를 가리킨다. 이 중 port넘버가 주어지지 않으면 요청된 서버의 기본 포트를 의미한다.

Host header는 모든 HTTP/1.1 요청 메시지에 포함되어야 한다. host가 없거나 한개 이상의 host가 있다면 400에러 상태코드가 전송된다.

 

 

- Accept : MIME 타입으로 표현되는, 클라이언트가 이해 가능한 컨텐츠 타입이 무엇인지 서버에 알려주는 역할을 한다. 

컨텐츠 협상을 이용해서 서버는 제안 중 하나를 선택하고 Content-Type 응답 헤더를 통해 클라이언트에게 알려준다. 브라우저는 요청이 이루어진 컨텍스트에 따라 이 값에 적당한 타입을 설정한다. 예를 들어 Css stylesheet을 서버에 요청할 때와 image, video와 같은 데이터를 요청할 때 다른 값이 설정.

 

 

- Cookie : HTTP cookies를 포함한다. 예를 들어 자바스크립트에서 Document.cookie를 통해 지정된 쿠키나, 최근 서버로 부터 Set-cookie를 통해 보내져온 쿠키들이 포함된다. 쿠키 헤더는 선택적이고 브라우저에서 사생활 보호 설정이 되어있다면 생략될 수 있다. 

 

여기서 궁금했던 것이 Cookie는 forbidden header로 분류되는데, 어떻게 개발자가 Document.cookie를 통해서 쿠키를 지정하게 된다는 거지? 라는 거였다. Document.cookie로 쿠키를 지정한다는 것이 직접적으로 HTTP request메시지를 수정한다는 의미는 아니였다. 브라우저 안에 cookie를 넣어주는 것이고 그것을 결국 브라우저가 적절하게 사용하게 되는 것. 

 

 

- User-agent : 요청하는 사용자 에이전트의 어플리케이션, 운영 체제, 공급 업체 또는 버전을 서버와 네트워크 peers들이 식별할 수 있게 한다. 

 

특정 브라우저에서 이 기능이 동작하는지나 버그를 확인하기 위해, 특정 브라우저에 따라 다른 HTML제공하기 위해서 user-agent 헤더를 사용하는데, 브라우저별로 다른 웹페이지 혹은 서비스를 제공하는 것은 일반적으로 좋은 방법이 아니다. 웹은 사용자가 어떤 브라우저나 디바이스를 사용하고 있는 지에 개의치 않고 모두에게 접근성이 좋아야 하기 때문이다. 특정 브라우저를 타겟으로 개발하는 것보다 Web API등을 이용해서 웹사이트를 개선하는 것을 권유한다. 

 

하지만 웹 표준은 완벽하지 않기 때문에 브라우저 감지 기능이 필요할 때가 있다. user-agent 헤더를 이용하여 브라우저를 감지하는 것은 간단해 보이지만 이것을 잘 이용하는 것은 힘들다. 브라우저 마다 지원하는 기능이 다르고, 브라우저의 버전마다 또 다르기 때문. 참고자료 : https://developer.mozilla.org/ko/docs/Web/HTTP/Browser_detection_using_the_user_agent

 

 

- Referer : 리소스에 대한 요청을 보낸 페이지의 절대 or 부분 주소를 포함한다. 서버는 이를 통해 방문자가 어디에서 왔는지 또는 요청된 리소스가 사용되는 곳을 식별할 수 있게 된다. 만약 사용자가 어떤 링크를 타고 들어왔다면, Referer는 해당 링크를 포함하고 있는 주소를 포함하게 된다. 이 데이터는 분석, 로깅, 최적화된 캐싱 등에 사용될 수 있다. 

 

이것을 함부로 사용하면 프라이버시, 보안 문제를 야기할 수 도 있다. 예를 들어 클릭하면 패스워드를 초기화 시킬 수 있는 '패스워드 초기화' 링크를 생각해보면, 링크와 referer를 통해 해당 사용자의 비밀번호 재설정 URL을 알게 될 수 있다. 이것을 저장하고 계속 사용할 수 도 있으니 사용자의 보안이 위험에 노출되는 것.

 

이러한 위험은 어플리케이션을 합리적으로 설계함으로써 완화될 수 있다. 한번만 사용 가능한 비밀번호 재설정 URL, 혹은 그 URL을 고유한 유저의 토큰과 결합하는 방식과 같은 것. 그리고 민감한 데이터를 안전한 방식으로 전송함으로써 위험을 줄일 수도 있다. 민감한 데이터일 경우 가능하다면 GET 대신 POST를 사용하여 다른 위치로 전달되지 않도록 해야 한다. 

 

또한 Referrer-Policy헤더를 통해 Referrer헤더를 통해 전송되는 정보를 제어할 수 있다. no-referrer지시어는 Referer 헤더를 생략하게 한다. 누출이 되면 안되는 HTML요소(<a>, <img>..) 에 referrerpolicy속성을 noreferrer로 설정해서 사용할 수 있다. 문서 전체에 적용하기 위해서는 refererrpolicy 이름을 가졌고 내용이 no-referrer로 된 <meta> 요소를 사용하면 된다. 

 

+ 대부분의 웹이 HTTPS를 사용하고 있긴 하지만, 사용하고 있지 않다면 고려해봐야한다. HTTPS는 Referer정보를 HTTPS가 아닌 사이트로 전송하지 않기 때문. 

 

 

- Authoriaztion : 서버와 user-agent간 자격 증명을 위해 사용된다. 자격 증명을 통해 인증이 제공되고 이를 통해 보호된 리소스에 접근할 수 있다. 

 

Authorization: <auth-scheme> <authorization-parameters>

 

<auth-scheme>은 인증이 어떤 방식으로 인코딩 되었는지 알려준다. ex) Basic, Digest, Negitate, AWS4-HMAC-SHA256

 

* Basic scheme

Authorization: Basic <credentials>

'Basic'스킴이 사용되었다면 증명은 사용자명과 비밀번호가 콜론을 이용해서 합쳐지고, 그 문자열을 base64로 인코딩하여 생성된다. base64는 암호화나 해싱을 의미하지 않기 때문에 복호화가 가능하다. 사실 문자를 그대로 보내는 것과 동일하다고 할 수 있다. Basic인증을 하는 경우 HTTPS로 접속하는 것을 권장.

 

 

- Origin : 요청을 발생시키는 출처(scheme, hostname, port)를 나타낸다. 만약 user-agent가 페이지의 리소스들을 요청하거나, 실행하는 스크립트에서 데이터를 요청해야 하는 경우 페이지의 출처가 요청에 포함될 수 있다. 

Origin: null
Origin: <scheme>://<hostname>
Origin: <scheme>://<hostname>:<port>

출처 요청에 대한 보안 컨텍스트를 제공하기 위해 사용된다. Referer와 비슷하지만 '경로' 자체를 공개하지는 않는다. null일 수도 있다. 출처 정보가 민감하거나 불필요한 경우를 제외하고 항상 포함된다. 

 

user-agent는 일반적으로 다음과 같은 요청에 Origin헤더를 추가한다.

 

 * 교차 출처 요청

 * GET 또는 HEAD 요청을 제외한 동일 출처 요청. 즉 POST, OPTIONS, PUT, PATCH 및 DELETE 동일 출처 요청에 추가된다.

 

위 규칙에는 예외가 있는데, 교차 출처 GET, HEAD요청이 no-cors모드로 수행되는 경우 Origin 헤더는 추가되지 않는다. 

 

 

 

3) Response header (응답 헤더)

 

- Server : 요청을 처리하고 응답을 생성하는 origin 서버의 소프트웨어 정보이다. 서버에 대한 지나치게 상세한 정보는 보안 공격을 받을 수 있는 통로가 될 수 있으니 조심해야 한다. 

 

Server: <product>
ex) Server: Apache/2.4.1 (Unix)

 

- Set-Cookie : 서버가 user-agent에게 쿠키를 보내기 위해 사용된다. 보내 줌으로써 user-agent는 이후에 다시 서버에 쿠키를 보내줄 수 있다. 다수의 쿠키들을 보내기 위해서는 다수의 Set-cookie 헤더들을 같은 응답에 보내야 한다. 

 

Set-Cookie 지시문들

* Set-Cookie: <cookie-name>=<cookie-value> 
: 이름 = 값 페어로 구성된다. 


* Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
: Expires는 쿠키의 수명을 가리킨다. 지정되지 않았다면 세션 쿠키로 취급된다. 클라이언트 종료시 파기.
: 하지만 일반적으로 브라우저에서는 세션 복원기능을 제공한다. (탭을 기억했다가 브라우저를 켜면 다시 복구되는)
: 쿠키 또한 복원 되므로 브라우저를 닫은 적이 없게되는 것.
: Expires 시간이 정해지면 데드라인은 서버가 아닌 클라이언트에 쿠키가 set되어진 시점을 기준으로 동작한다.


* Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>
: 쿠키가 만료될 때 까지의 시간을 나타낸다. 0또는 음수가 되면 쿠키는 즉시 만료.
: 브라우저는 Expires와 Max-age가 둘다 지정되었을 때 Max-age값을 더 우선시한다.


* Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
: 쿠키가 보내져야 하는 호스트를 지정한다. 지정되어 있지 않으면 현재 문서 URI를 기준으로 적용.
: 여러 호스트/도메인 값을 지정할 수 없지만, 도메인이 지정되면 하위 도메인이 포함된다.


* Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
: 브라우저가 쿠키 헤더를 보낼 때 URL에 반드시 포함되어야하는 경로를 나타낸다.
: 예를들어 서버에서 '/example.com'을 Path지시문을 통해 보냈다면
: 'http://example.com/another.html'으로 보낸 클라이언트 요청에는 쿠키를 보내겠지만
: 'http://another.html'로 온 요청에는 쿠키를 보내지 않게 되는 것.


* Set-Cookie: <cookie-name>=<cookie-value>; Secure
: 요청이 오직 https: 스킴으로 만들어졌을 때만 서버에 쿠키를 보내야 함을 나타낸다.
: 이 속성을 지정하였다고 해서 민감한 정보에 대한 모든 접근을 막을 수 있는 것은 아니다.
: HTTPOnly 속성이 지정 되어있지 않다면 쿠키들은 클라이언트의 하드디스크, 자바스크립트를 통해 읽고 변경될 수 있다.


* Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly
: HTTPOnly로 쿠키를 생성하였어도 클라이언트 Javascript를 통해 시작된 요청(fetch..)에 의해 응답 되어진다.
: 하지만 해당 속성을 통해 Javascript의 Document.cookie와 같은 속성을 통해 쿠키에 접근하는 것을 금지한다.
: XSS 공격을 막는데 도움이 된다. *공격자가 웹사이트에 악성 클라이언트 측 코드를 삽입하여 실행시키는 보안 취약점


* Set-Cookie: <cookie-name>=<cookie-value>; SameSite=<sameSite값>
: 크로스 사이트 요청에서의 쿠키 전송을 제어하여 크로스 사이트 요청 위조(CSRF)에 대한 보호를 일부 제공한다.
: sameSite값에 가능한 값은 Strict, Lax, None 이 있다.


: Strict은 브라우저가 쿠키를 보낼 때, 동일한 사이트에서 시작된 요청에만 보내도록 지정한다. 
: 도메인이나 scheme이 다른 경우 SameSite=Strict 속성이 지정된 쿠키는 전송되지 않는다. 


: Lax는 쿠키가 이미지나 프레임을 로드하는 크로스 사이트 요청에는 전송되지 않지만,
: 사용자가 외부 사이트에서 원래 사이트로 이동하는 경우에는 전송된다. SameSite의 default값이다.


: None은 크로스 사이트 및 동일한 사이트 요청 모두에 전송가능하도록 지정하는 것.
: 이 값을 설정할 때는 Secure속성도 설정 해주어야한다. SameSite=None; Secure


* 여러개의 지시문을 함께 사용하는 것도 가능하다.
: ex) Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly

 

- Expires : 응답이 더 이상 fresh하지 않다고 판단할 날짜 / 시간을 포함한다. max-age, s-max-age 디렉티브를 지닌 Cache-Contrl 헤더가 존재하면 Expires헤더는 무시된다. 

 

- Allow : 리소스가 지원하는 메소드 집합을 알려준다. 어떤 요청 메소드를 사용할 수 있는지 알려주기 위해 서버가 405 상태코드로 응답할 경우에 이 헤더를 반드시 보내야 한다. Allow 헤더가 비어있다면 어떤 요청 메소드도 허용하지 않겠다는 것. 

Allow: <http-methods>
ex) Allow: GET, POST, HEAD

 

- Access-Control-Allow-Origin : 이 응답이 주어진 origin으로부터의 요청 코드와 공유할 수 있는 지를 나타낸다.

Access-Control-Allow-Origin: *
: *는 모든 요청 코드를 허용한다는 의미이다. credential과 함께 사용하려고 하면 오류가 발생한다.

Access-Control-Allow-Origin: <origin>
: origin을 명시할 경우 하나의 origin만 명시될 수 있다. 
: 서버가 명시적인 origin을 이 지시문과 함께 보내면 응답은 Vary헤더 또한 포함해야 한다.
: 서버가 Origin 요청 헤더의 값에 따라 다르게 응답할 수 있음을 브라우저에 알리기 위해서 이다.

: ex)
Access-Control-Allow-Origin: https://developer.mozilla.org
Vary: Origin

 

<origin>을 지정하였다면, 요청 헤더의 Origin을 검사하는 서버 측 코드가 필요하다. 요청 헤더의 Origin을 가지고 있는 허용된 origin 리스트와 비교해보고, 그 안에 있다면, Access-Control-Allow-Origin 값을 Origin과 동일한 값으로 설정하는 식으로 로직이 진행된다. 

 

 

- Age : 객체가 프록시 캐시 내에 머무른 초단위의 시간을 나타낸다. 보통 0에 가깝다. 만약 0이라면 그것은 원 서버로부터 막 내려받았다는 의미이다. 

 

 

- Location : 페이지를 리디렉션 할 URL을 나타낸다. 

Location: <url>
ex) Location: /index.html

상태코드가 3xx(redirection) or 201(created) 인 응답과 함께 전송된다. Location에서 지정된 페이지를 가져오기 위해 새로운 요청을 만드는데, 이 때 HTTP method는 원래 method와 redirection 유형에 따라 다르다. 

 

303 (See Other) 응답은 항상 GET 방법을 사용한다.
307 (Temporary Redirect) 및 308 (Permanent Redirect)은 원래 요청에서 사용된 방법을 변경하지 않는다.
301 (Moved Permanently) 및 302 (Found)는 대부분 방법을 변경하지 않지만, 오래된 user-agent에서는 변경할 수도 있다.

 

Location과 Content-Location 헤더는 다르다. Location의 경우 리디렉션 할 타겟이나 새로 생성된 리소스의 URL을 가리키는 반면,

Content-Location은 컨텐츠 협상이 발생한 경우에 추가 협상 없이 리소스에 접근하기 위한 직접적인 URL을 나타낸다. 

Location은 응답 헤더이며, Content-Location은 Entity header로 구분된다.

 

 

4) Payload headers(Entity headers)

 

- Content-Length : 수령인에게 보내지는 message body의 사이즈. 바이트(bytes)로 나타낸다. 

 

- Content-Language : 듣는 사람을 위한 언어를 알려주기 위해 사용된다. 유저는 유저의 선호에 따라 언어를 구분할 수 있다.

Content-Language: de-DE

예를 들어 Content-Language가 위처럼 설정되어 있다면, 해당 문서가 독일어 사용자를 대상으로 한다는 것을 나타낸다. 다만 문서가 독일어로 작성되었다는 것을 의미하지는 않는다. 독일어 사용자를 대상으로한 영어 교육자료일 수 있음. 문서가 작성된 언어를 나타내려면 lang 속성을 이용할 수 있다. 

 

Content-Language가 지정되지 않았다면, 기본값은 모든 언어를 대상으로 한다는 것이다. 여러 언어 태그도 가능하고, 텍스트 문서 뿐만 아니라 미디어 유형에도 적용할 수 있다. 

 

- Content-Encoding : 메시지에 적용된 인코딩들과 순서를 알려준다.

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: br

//다수일 때
Content-Encoding: deflate, gzip

이를 통해 수신자는 원래 값을 얻기 위해 디코딩하는 방법을 파악할 수 있다. 컨텐츠 인코딩은 원 데이터의 유형에 대한 정보를 유지하면서 메시지 데이터를 압축하는 데 사용된다. 

 

- Content-Type : 원본 리소스의 타입을 나타낸다. encoding보다 선행되기 때문에 encoding전의 타입을 알 수 있다. 

Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something

 

응답에서, Content-Type 헤더를 통해 클라이언트는 응답받는 실제 컨텐츠의 타입을 알 수 있게 된다. 때로 브라우저들은 MIME-sniffing으로 이 헤드의 값을 꼭 따르지 않기도 한다. 이것을 원하지 않는 다면 X-Content-Type-Option 헤더를 nosniff로 설정할 수 있다. 

 

 

- Expires : 헤더의 응답이 더 이상 fresh하지 않다고 판단할 날짜/시간. 0과 같이 유효하지 않은 날짜는 리소스가 이미 만료되었음을 나타낸다. 응답에 max-age, s-max-age 지시문을 지닌 Cache-Control 헤더가 존재할 경우 Expires헤더는 무시된다. 

 

 

 

 

 

공부 하고 나니 좀 달라보이기 시작한다. 달라보여서 다행이다..

공부를 하면서 컨텐츠 협상과 HTTP 보안관련해서 여러 위험들(XSS, CSRF..) 에 대한 개념이 나왔는데 다음은 이것들에 대해 알아보려고 한다. 

 

 

참고사이트

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers