[ 살펴보기 ] HTTP

Client와 Server사이에 http protocol을 통해 communication을 할 때 발생하는 http message는 ( request와 response ) http header에 각 messag에 대한 추가 정보를 설정해 전달한다. 예를 들어 request의 경우 server에 전달한 cookie나 request의 user-agent 정보를 http header에 설정하여 전달하고 response의 경우 cache-control policy나 content-type과 같이 client가 response를 어떻게 해석하고 어떻게 cache해야 하는지 등의 정보를 http header에 설정하여 전달한다.

request 혹은 response에 설정할 수 있는 header는 매우 다양하지만 우선 대표적인 header 위주로 살펴보자. HTTP header는 크게 Request headers, Response headers, Representation headers, Payload headers로 나뉜다. 이전에는 Request headers, Response headers에서 모두 포함되는 headers를 의미하는 General header라는 용어도 사용했지만 현재는 outdated 되었다. ( Reference - MDN General header )

Request headers

Request에 설정할 수 있는 header로서 request를 전달 받는 server는 request의 일부 header를 통해 필요한 request를 검증하거나 경우에 따라선 request를 거부할 수도 있다. Request에 설정할 수 있는 header는 다양하지만 그 중 일부는 다음과 같다.

Host : server의 domain name을 나타내는 header. 만약 browser를 통해 https://example.com/about page에 접속하면 host는 example.com이 된다.
```
  Host: example.com
```
Origin : request를 요청한 origin ( scheme, hostname, port ) 정보를 나타내는 header. 만약 https://test.com/about 페이지에서 https://example.com/news로 request를 요청하면 request의 origin header는 https://test.com이 된다.
```
  Origin: https://test.com
```
Referer : link를 통해 다른 page 혹은 site로 이동했을 때 이동 하기 전 page의 url을 나타낸다. 예를 들어 https://test.com/about 페이지에서 link를 통해 https://test.com/about으로 이동한다면 이동할 때 발생하는 request의 referer header는 https://test.com/about이다.
```
  Referer: https://test.com/about
```

User-Agent : request를 보내는 client의 정보를 나타내는 header
```
  User-Agent: Mozilla/5.0
```
Authorization : server가 bearer token을 통해 user를 인증할 때 token 값을 설정하는 header
```
  Authorization: Bearer a12dfw4…
```
Accept : client가 처리할 수 있는 resource의 media type을 나타내는 header
```
  Accept: application/json
```
Accept-Encoding : client가 처리할 수 있는 content encoding type을 나타내는 header
```
  Accept-Encoding: gzip, deflate
```
Accept-Language : client가 선호하는 language 정보를 나타내는 header. Browser setting에 따라 user가 site를 방문할 때 Accept-language header에 추가되는 language 정보가 달라질 수도 있다.
```
  Accept-Language: en-US, fr
```
Cookie : request와 함께 전달하는 cookie value를 나타내는 header
```
  Cookie: testNumber=123; myValue=abc
```
Cache-Control : resource의 cache mechanism을 설정한다. cache-control : max-age=1000과 같이 client가 resource를 cache하는 기간을 설정하거나 cache-control: no-store와 같이 client가 resource를 cache하지 않도록 설정할 수도 있다.
```
  Cache-Control: no-store
```
If-Modified-Since : request하는 resource가 If-Modified-Since header에 설정된 시간 이후에 수정되었을 때만 resource를 request한다.
```
  If-Modified-Since: Tue, 10 Jan 2023 12:00:00 GMT
```
If-None-Match : resource의 ETag 값과 If-None-Match header의 ETag 값이 일치하지 않을 때만 resource를 request한다.
```
  If-None-Match: "xyz123..."
```
Connection : request 요청 이후에도 server와 connection을 유지할 것인지를 나타내는 header. connection header를 keep-alive으로 설정하더라도 server의 setting이나 browser의 timeout과 같은 요소에 따라 conenction이 종료될 수 있다.
```
  Connection: keep-alive
```

Response headers

Content-Type : response body의 content type을 나타내는 header. 아래 예제에서 client는 response body를 html type으로 해석한다.
```
  Content-Type: text/html; charset=UTF-8
```
Content-Length : response body의 size를 나타내는 header
```
  Content-Length: 1234
```
Content-Encoding : response body에 적용된 compression 방식을 나타내는 header
```
  Content-Encoding: gzip
```
Set-Cookie : client로 전달할 cookie를 설정하는 header. 아래 예제는 HttpOnly option을 가진 sessionId라는 cookie를 설정하여 client로 전달한다.
```
  Set-Cookie: sessionId=abc123; HttpOnly
```
Cache-Control : resource의 cache mechanism을 설정한다. cache-control : max-age=1000과 같이 client가 resource를 cache하는 기간을 설정하거나 cache-control: no-store와 같이 client가 resource를 cache하지 않도록 설정할 수도 있다.
```
  Cache-Control: no-store
```
Server : server software의 정보를 나타내는 header
```
  Server: nginx/1.18.0
```
Date : response가 생성된 시간 정보를 나타내는 header
```
  Date: Wed, 15 Jan 2025 10:00:00 GMT
```
Connection : response 이후에도 client와 connection을 유지할 것인지 여부를 나타내는 header. Keep-Alive header를 통해 별도로 conenction 유지 시간을 명시하지 않으면 default로 적용되는 유지 시간은 server software ( nginx, apache 등 )에 따라 다르다.
```
  Connection: keep-alive
```
Keep-Alive : connection header가 keep-alive일 때 connection을 얼마 동안 유지할 것인지 또는 유지하는 conenction에서 얼마나 많은 request를 허용할 것인지를 나타내는 header ( ex - timeout=5, max=200 ). time option은 connection 유지 시간을 second로 나타내고 max option으로 connection 유지 시간 동안 같은 connection에서 허용할 최대 request 수를 나타낸다.
```
  Keep-Alive: timeout=5, max=200
```
Last-Modified : resource가 마지막에 수정된 date 정보를 나타내는 header
```
  Last-Modified: Mon, 13 Jan 2025 15:45:00 GMT
```
ETag : response resource의 unique identifier를 나타내는 header. client가 cache resource를 다시 사용해도 되는지 여부를 판단할 때 사용된다.
```
  ETag: "34f7a311"
```
Location : resource 요청을 위해 client가 redirect 해야 하는 url을 나타내는 header
```
  Location: https://new-example.com
```
Accept-Ranges : server가 partial request를 지원하는지 여부를 나타내는 header. 어떤 data unit으로 partial request를 지원하는지 명시한다.
```
  Accept-Ranges: bytes
```
X-Content-Type-Options : browser가 MIME type sniffing하지 못하도록 방지할 때 사용할 수 있는 header
```
  X-Content-Type-Options: nosniff
```
X-Frame-Options : resource가 iframe에 embed될 수 있는지 여부를 나타내는 header. 현재 deprecated 되었으며 대신 Content-Security-Policy header를 사용할 수 있다. ( Reference - X-Frame-Options )
```
  X-Frame-Options: DENY
```
X-XSS-Protection : browser가 cross site scripting을 감지하면 page load를 막는 filter 기능을 사용할 것을 나타내는 header. 현재 deprecated된 header이며 대신 Content-Security-Policy header를 사용할 수 있다. ( Reference - X-XSS-Protection ) 1로 설정하면 filter를 적용하라는 뜻이며 0으로 설정하면 filter 기능을 적용하지 말라는 뜻이다.
```
  X-XSS-Protection: 1; mode=block
```
Content-Security-Policy : client가 어떤 resource를 load할 수 있는지 통제하는 header. img-src, frame-src, script-src등 다양한 directive와 origin 정보를 명시하여 resource가 명시한 origin에서만 load될 수 있도록 통제할 수 있다. 예를 들어 Content-Security-Policy header가 아래와 같다고 가정해보자.
```
  Content-Security-Policy: img-src 'self' https://test-image.com data:
```
위의 header에서 img-src로 'self', https://test-image.com, data: 세 개의 origin 정보를 명시하고 있다. 그리고 현재 접속하는 page의 html file을 제공하는 server origin이 https://example.com이라고 한다면 아래의 image는 정상적으로 load된다.
```
  <img src="https://example.com/images/banner.jpg">

  <img src="https://test-image.com/photo.jpg">

  <img src="data:image/png;base64,iVBASd0KGgoAABDSDF...">
```
반면 다음 image는 header에 명시되어 있는 origin에서 load하는 image가 아니므로 정상적으로 load되지 않는다. 두 번째 예제는 domain은 같지만 protocol이 https가 아닌 http이므로 load되지 않는다. 반면 header에서 명시한 origin의 protocol이 http였다면 https를 사용한 image load는 허용된다. ( Reference - MDN Scheme-resource )
```
  <img src="https://different.com/image.jpg">

  <img src="http://test-image.com/photo.jpg">
```
script file 또한 다음과 같이 load origin을 통제할 수 있다. 마찬가지로 현재 페이지 html file을 제공하는 server의 origin이 https://example.com이고 header가 다음과 같다고 가정해보자.
```
  Content-Security-Policy: script-src 'self' https://my-script.com
```
header가 위와 같을 때 아래 script는 정상적으로 load된다.
```
  <script src="https://example.com/js/app.js"></script>

  <script src="https://my-script.com/main.js"></script>
```
또한 frame-src를 통해 page에서 어떤 origin을 iframe을 통해 load할 수 있는지 역시 통제할 수 있다. 마찬가지로 현재 페이지 html file을 제공하는 server의 origin이 https://example.com이고 header가 아래와 같다고 가정해보자.
```
  Content-Security-Policy: frame-src 'self' https://*.youtube.com
```
header가 위와 같을 때 아래 iframe은 정상적으로 content가 load된다.
```
  <iframe src="https://example.com/about"></iframe>

  <iframe src="https://youtube.com/embed/video-id"></iframe>
```
반면 frame-ancestor directive는 server에서 제공하는 page가 어떤 origin에서 iframe을 통해 embed될 수 있는지 제한한다. 예를 들어 현재 우리가 서비스를 제공하고 있는 server의 origin이 https://example.com이고 header가 아래와 같다고 가정해보자.
```
  Content-Security-Policy: frame-ancestors 'self' https://test.com
```
위의 예제에서 https://example.com과 https://test.com에서 https://example.com origin의 page를 iframe으로 load할 수 있지만 다른 origin에선 load할 수 없다.
```
  // https://example.com/order 페이지에서 아래 iframe은 정상적으로 load
  <iframe src="https://example.com/about"></iframe>

  // https://test.com/detail 페이지에서 아래 iframe은 정상적으로 load
  <iframe src="https://example.com/about"></iframe>

  // https://aabbcc.com/detail은 허용된 origin이 아니므로 
     해당 페이지에선 아래 iframe이 load되지 않는다.
  <iframe src="https://example.com/about"></iframe>
```
여러개의 directive를 설정할 경우 다음과 같이 ;으로 구분한다.
```
  Content-Security-Policy: connect-src http://example.com/;
                           script-src http://example.com/
```
Content-Security-Policy header의 특정 directive는 다른 directive의 fallback 역할을 한다. 예를 들어 여러 directive를 함께 선언할 때 img-src가 명시되어 있지 않고 default-src directive가 명시되어 있으면 default-src에 명시되어 있는 값이 img-src와 다른 fetch directive의 default fallback으로 사용된다.
```
  Content-Security-Policy: default-src http://example.com/;
                           script-src http://example.com/
```
Strict-Transport-Security : client에게 http가 아닌 https를 통해 server와 통신할 것을 강제하는 header. max-age option으로 client가 해당 server는 https로만 접속할 수 있음을 기억하고 있는 기간을 second로 명시하고 includeSubDomains option은 해당 site의 subdomain에도 같은 rule을 적용한다.
```
  Strict-Transport-Security: max-age=31536000; includeSubDomains
```
Access-Control-Allow-Origin : cross origin request가 발생할 때 어떤 origin에 대한 request를 허용할 것인지 나타내는 header
```
  Access-Control-Allow-Origin : https://test.com
```
Access-Control-Allow-Methods : cross origin request가 발생할 때 어떤 method를 허용할 것인지 나타내는 header
```
  Access-Control-Allow-Methods: GET, POST, PUT, DELETE
```
Access-Control-Allow-Headers : cross origin request가 발생할 때 어떤 header를 허용할 것인지 나타내는 header
```
  Access-Control-Allow-Headers: Content-Type, Authorization
```