HTTP 학습 (3-3) - 응답 헤더 필드

* HTTP/1.1을 기준으로 작성되었습니다.

응답 헤더 필드는 서버에서 클라이언트로 송신하는 리스폰스 메시지에 쓰이는 헤더로, 리스폰스의 부가 정보와 서버의 정보 그리고 클라이언트에 부가 정보 요구 등을 나타낸다.

 

 

 

1. Accept-Ranges

클라이언트가 Range 헤더 필드를 통해 서버에게 리소스의 일부만을 요청할 수 있었는데, 이 때 서버가 부분 요청에 대해 응할 수 있는지 여부를 확인할 때 Accept-Ranges 헤더 필드를 사용한다.

서버가 리소스의 일부만을 줄 수 있는지 여부를 알려주는 헤더 필드이다. 클라이언트는 해당 헤더를 보고 가능하다면 Range 헤더 필드로 리소스의 일부를 받아올 수 있다.

값으로는 bytes와 none이 있는데, bytes는 일부 요청이 가능하다는 것이고 none은 불가능하다는 것이다. bytes 외 다른 값은 HTTP/1.1 명세에 정의되어있지 않기에 두가지 값만 존재한다 생각하면 된다.

 

 

2. Age

오리진 서버에서 생성된 리스폰스가 현재까지 얼마나 경과했는지 알려주는 헤더 필드이다. 초 단위로 나타내며, 보통 이는 캐싱과 관련되어 사용된다.

오리진 서버에서 생성되어 캐시 서버에 리소스가 저장될텐데, 저장되어있는 동안 Age 값이 커질테고(오리진 서버로부터 나간 뒤 시간은 흐를테니깐) 이 Age 값으로 캐시 서버에 리소스가 얼마나 있었는지 파악할 수 있게 해준다.

캐시 서버에 리소스가 오래 있었다고 무조건 안 좋은 것은 아니다. 리소스가 변경되지 않았다면 굳이 오리진 서버에서 새로 통신하여 받아 올 필요가 없고 캐시 서버에 있는 기존의 리소스를 사용하면 의미없는 리소스 교환이 이루어지지 않아 효율을 올릴 수 있을 것이다. 

이는 일반 헤더의 Cache-Control에 max-age값을 설정함으로써 할 수 있는데 이는 일반 헤더에서 다루었으니 자세한 건 넘어가겠다.

 

 

3. ETag

ETag는 엔티티 태그라고 불리며 각 리소스들을 특정하기 위한 문자열로 이루어진 고유값이라 할 수 있다. 동일한 URI를 가진 요청이더라도 리소스의 내용이 변경된다면 ETag 값도 변경된다.

ETag는 강력한 ETag값과 약한 ETag 값으로 구별되어 있다. 강한 ETag값은 바이트 단위로 컨텐츠가 모두 동일해야하며 엔티티가 아주 조금만 다르더라도 변경된다. 약한 ETag값은 바이트 단위로 동일하지는 않지만 의미적으로 다른 리소스만 ETag값이 변경된다. 약한 ETag값의 앞부분에는 'W/'가 붙는다.

ETag를 활용하여 캐싱된 컨텐츠들이 갱신이 필요한지 여부를 판단할 수있고 다운로드 도중 끊겨서 다시 받을 때도 ETag를 활용하는 등 ETag에는 다양한 쓰임새가 있다.

 

 

4. Location

클라이언트에게 리소스의 새로운 위치를 알려주는 데 사용되는 헤더 필드이다. 이는 새로운 웹페이지로 안내해줄뿐 아니라 요청을 더 올바른 위치로 전달하도록 도와주기도 한다. 

보통 300대의 상태코드와 함께 사용되며 클라이언트는 해당 안내를 받고 올바른 위치에서 리소스를 가져올 수 있게 된다.

 

 

5. Retry-After

클라이언트가 일정 시간 후에 리퀘스트를 다시 시행해야하는지 전달하는 헤더필드로 서버가 클라이언트한테 다시 일정 시간 후 다시 실행해달라 안내하는 것이다. 서버가 일시적으로 과부하 되었거나 유지보수중일 때 등 클라이언트에게 대응하기 위해 사용된다 한다.

그러나 브라우저에 따라 해당 헤더를 무시하기도 한다고 그런다. 

 

 

6. Server

서버에 설치되어 있는 HTTP 서버의 소프트웨어를 전달한다. 단순히 명칭뿐만 아니라 버젼이나 옵션도 기재되는 경우가 있다. 

Server: Apache/2.4.41 (Unix) OpenSSL/1.1.1d PHP/7.4.3

 

자세한 정보가 보여지면 보안에서 문제가 발생할 수 있으므로 자세한 정보를 감출 수도 있다고 한다.

 

 

7.Vary

Vary의 값은 HTTP 요청 헤더 이름이 들어가며 캐시를 컨트롤하기 위해서 사용한다. 클라이언트의 요청이 같은 리소스에 대한 요청이라도 Vary에 지정되어있던 헤더 필드가 다르다면 캐시 서버에서 리소스를 가져오는 것이 아닌 오리진 서버에서 다시 가져오게된다.

예를 들어 사용자가 'A' 이미지를 요청했는데 한 번은 모바일, 한 번은 데스크톱에서 요청하였다. 데스크톱에서 요청했을 시 첫 번째 요청과 동일한 이미지 리소스이기에 캐시 서버는 오리진 서버에서 굳이 새로 받지 않고 기존에 모바일 때 요청했던 리소스를 데스크톱의 요청 시에 전달하게된다.

이 때 Vary: User-Agent를 달아준다면 첫 번째 요청은 모바일에서 요청했다는 것을 알고 다시 요청했을 때 여전히 User-Agent가 모바일일 때만 캐시 서버에 저장되어있는 리소스를 전달하게 된다.

 

 

8. WWW-Authenticate

서버에 접근할 자격이 없는 클라이언트가 접근했을 시 클라이언트에 인증을 요청하는 헤더 필드며 주로 HTTP/1.1 401 Unauthorized 상태코드와 같이 사용된다. 보통 접근 가능한 클라이언트를 구별하는 것은 백엔드에서 직접 구현할 수도 있지만 HTTP 프로토콜에서 제공하는 WWW-Authenticate 헤더 필드를 이용하여 보안기능을 구축할 수도 있다.

클라이언트는 WWW-Authenticate에 따라 Authorization를 요청 헤더에 실어서 재요청 해야한다. 

 

 

9. Proxy-Authenticate

Proxy-Authenticate는 WWW-Authenticate와 비슷한 기능인데, WWW-Authenticate는 오리진 서버가 클라이언트에게 인증을 요청한 반면, Proxy-Authenticate는 프록시 서버가 클라이언트에게 인증을 요청하는 것이다.

Proxy-Authenticate는 WWW-Authenticate 와 달리 407 Proxy Authentication Required 상태코드가 같이 사용된다.

 

 

 

---

참고 문서

• [HTTP 프로토콜 강좌]#16 HTTP 응답 헤더 I - Accept-Range, ETag, Location, Server, Vary  - https://withbundo.blogspot.com//search/label/HTTP?updated-max=2017-08-08T15:43:0%2B09:00&max-results=1&pgno=5