[웅's HTTP 완벽가이드] 3장 (2편) - 상태 메시지와 헤더 총정리 (HTTP/1.1까지)

'HTTP 완벽 가이드' 책을 읽고 정리한 내용입니다.

 

출저: 인터넷 교보 문고

 

1장 HTTP 기초 링크 : https://codeboyed.tistory.com/17

2장 URL과 리소스 링크 :  https://codeboyed.tistory.com/19

3장(1편) HTTP 메시지 중 메소드 : https://codeboyed.tistory.com/23 

 

3장은 HTTP 요청과 응답 시 사용되는 HTTP 메시지에 관한 내용입니다. 

내용이 상대적으로 많아서 1편과 2편으로 구성했습니다.

 

개발자 도구의 네트워크 탭을 열어, HTTP 메시지에 어떤 요소가 있는 지 한 번 보는 것도 좋을 것 같습니다.

 

3.4 상태코드

HTTP 상태 코드는 크게 5가지로 나뉜다. 상태 코드는 클라이언트에게 그들의 트랜잭션을 이해할 수 있는 쉬운 방법을 제공한다. 

 

3.4.1 100-199 : 정보성 상태 코드

 

상태코드	사유	의미
100	Continue	요청의 시작 부분 일부가 받아들여졌으며, 클라이언트는 나머지를 계속 이어서 보내야 함을 의미한다.

 

100 Continue는 HTTP 클라이언트 애플리케이션이 서버에 엔터티 본문을 전송하기 전에 그 엔터티 본문을 서버가 받아들일 것인지 확인하려고 할 때, 그 확인 작업을 최적화하기 위한 의도로 도입된 것이다.

 

클라이언트와 100 Continue

 

만약 클라이언트가 엔터티를 서버에게 보내려고 하고, 그 전에 100 Continue 응답을 기다리겠다면, 클라이언트는 값을 100-Continue로 하는 Expect 요청 헤더를 보낼 필요가 있다.

100-Continue는 여러 측면에서 최적화를 위한 것이다. 클라이언트 애플리케이션은 서버가 다룰 수 없는 큰 엔터티를 서버에게 보내지 않으려는 목적으로만 사용한다.

하지만 100 Continue 명령 역시 초창기에 혼란이 있었기 때문에, 무조건 서버가 응답을 해주기를 기다리기만 기다리면 안된다. 클라이언트는 100 Continue 요청을 보낸 후 약간의 타임아웃 후에 그냥 엔터티를 보내야 한다.

 

서버와 100 Continue

 

서버가 100-Continue 값이 담긴 Expect 헤더가 포함된 요청을 받는다면, 100-Continue 응답 혹은 에러 코드로 답해야 한다. 서버는 절대로 100-Continue Expect 헤더가 담긴 요청이 들어오지 않은 경우에, 100-Continue 응답을 클라이언트에게 보내서는 안된다. ( 클라이언트가 오해하고 혼란을 초래한다. )

서버가 100-Continue 응답을 보낼 기회를 갖기 전에 어떤 이유로 인해 엔터티 일부를 수신했다면, 서버는 이 상태 코드를 응답할 필요가 없다. 왜냐하면 클라이언트는 이미 계속 전송하기로 결정했기 때문이다. 그러나 서버가 요청을 끝까지 다 읽은 후에는 그 요청에 대한 최종 응답을 보내야 한다.

 

3.4.2 200-299 : 성공 상태 코드

 

서버는 대응하는 성공을 의미하는 상태 코드의 배열을 갖고 있으며, 각각 다른 종류의 요청에 대응한다.

 

상태 코드	사유 구절	의미
200	OK	요청은 정상이고, 엔터티 본문은 요청된 리소스를 포함하고 있다.
201	Created	서버 개체를 생성하라는 요청(ex. PUT)을 위한 것. 응답은, 생성된 리소스에 대한 구체적인 참조가 담긴 Location 헤더와 함께, 그 리소스를 참조할 수 있는 여러 URL을 엔터티 본문에 포함해야 한다.
202	Accepted	요청은 받아들여졌으나 서버는 아직 그에 대한 어떤 동작도 수행하지 않았다. 서버가 요청의 처리를 완료할 것인지에 대한 어떤 보장도 없다. 단지, 요청이 받아들이기에 적법해 보인다는 의미의 코드이다. 서버는 엔터티 본문에 요청에 대한 상태와 가급적이면 요청의 처리가 언제 완료될 것인지에 대한 추정도 포함해야 한다.
204	No Content	응답 메시지는 헤더와 상태줄을 포함하지만 엔터티 본문은 포함하지 않는다. 주로 웹브라우저를 새 문서로 이동시키지 않고 갱신하고자 할 때 사용한다.
205	Reset Content	주로 브라우저를 위해 사용되는 또 하나의 코드, 브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우라고 말한다.
206	Partial Content	부분 혹은 범위 요청이 성공했다. 나중에 클라이언트가 특별한 헤더를 사용해서 문서의 부분 혹은 특정 범위를 요청할 수 있다는 것을 보게 될 것이다.

 

3.4.3 300-399 : 리다이렉션 상태 코드

 

리다이렉션 상태 코드는 클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 그 리소스의 내용 대신 다른 대안 응답을 제공한다. 만약 리소스가 옮겨졌다면, 클라이언트에게 리소스가 옮겨졌으며 어디서 찾을 수 있는지 알려주기 위해 리다이렉션 상태 코드와 Location 헤더를 보낼 수 있다. 이는 브라우저가 사용자를 귀찮게 하지 않고 알아서 새 위치로 이동할 수 있게 해준다.

 

리다이렉션 상태 코드 중 몇몇은 리소스에 대한 애플리케이션의 로컬 복사본이 원래 서버와 비교했을 때, 유효한지 확인하려 사용된다. 로컬 복사본이 여전히 최신인지 혹은 원래 서버에 있는 리소스가 수정되었는지 검사할 수 있다. 클라이언트는 문서가 특정 시점 이후에 수정된 경우에만 문서를 가져오라고 말하는 조건을 달아서 헤더를 전송하고, 서버는 조건에 충족할 경우 콘텐츠를 보내주고 그렇지 않을 경우 304 상태 코드로 응답할 것이다.

 

일반적으로, HEAD가 아닌 요청에 대해 리다이렉션 상태 코드를 포함한 응답에 리다이렉트 URL과 설명을 포함시키는 것이 좋은 습관이다.

 

상태 코드	사유 구절	의미
300	Multiple Choices	클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청한 경우, 그 소스의 목록들을 반환한다. 서버는 Location 헤더에 선호하는 URL을 포함시킬 수 있다.
301	Moved Permanently	요청한 URL이 옮겨졌을 때 사용한다. 응답은 Location 헤더에 현재 리소스가 존재하고 있는 URL을 포함해야 한다.
302	Found	301 상태 코드와 같다. 그러나 클라이언트는 Location 에 주어진 URL을 임시로 사용하고, 이후의 요청에는 원래의 URL을 사용해야 한다.
303	See Other	POST 요청에 대한 응답으로 클라이언트에게 리소스의 위치를 알려주는 것이다.
304	Not Modified	클라이언트는 헤더를 이용해 조건부 요청을 만들 수 있다. 만약 클라이언트가 GET 과 같은 조건부 요청을 보냈고 그 요청한 리소스가 최근에 수정된 일이 없다면, 이 코드는 리소스가 수정되지 않았음을 의미하게 된다.
305	Use Proxy	리소스가 반드시 프록시를 통해서 접근되어야 함을 나타내기 위해 사용한다. 프록시의 위치는 헤더의 Location을 통해 주어진다. 클라이언트는 이 응답을 특정 리소스에 대한 것이라고만 해석한다. 모든 요청이 이 프록시를 통해야 한다는 것은 아니다.
307	Temporary Redirect	301 상태 코드와 같다. 그러나 클라이언트는 Location 에 주어진 URL을 임시로 사용하고, 이후의 요청에는 원래의 URL을 사용해야 한다.

 

여기서 302, 303, 307 상태 코드가 거의 똑같은 것을 볼 수 있는데 이는 HTTP/1.0 과 HTTP/1.1 애플리케이션이 혼재되면서 생겨난 문제이다. HTTP/1.0 클라이언트가 POST 요청을 보내고 302 리다이렉트 상태 코드가 담긴 응답을 받으면, 클라이언트는 Location 헤더에 들어 있는 리다이렉트 URL을 GET 요청으로 따라갈 것이다.

HTTP/1.0 서버는 또 302 상태 코드를 보내면서 클라이언트가 리다이렉션 URL 에 대한 GET 요청으로 따라가기를 기대할 것이다. 

그런데 HTTP/1.1 이 등장하면서, HTTP/1.1 명세는 그러한 리다이렉션을 위해 303 코드를 사용하도록 했다. 때문에 HTTP/1.1 에서 일시적인 리다이렉트 상태를 의미하는 경우에는 307을 사용하고 302 상태 코드는 HTTP/1.0 클라이언트에게 사용하기 위해 남겨두었다.

결국 서버는 리다이렉트 응답에 들어갈 가장 적절한 리다이렉트 상태 코드를 선택하기 위해 클라이언트의 HTTP 버전을 검사할 필요가 있다.

 

3.4.4 400-499: 클라이언트 에러 상태 코드

 

가끔 클라이언트는 서버가 다룰 수 없는 무언가를 보낸다. 잘못 구성된 요청 메시지 같은 것이 있을 수 있으며, 가장 흔한 것이 존재하지 않는 것에 대한 URL 요청이다. 웹 브라우징을 하면서 우리는 모두 악명 높은 404 Not Found 요청을 만난 일이 있다. 이것은 서버가 우리에게 알 수 없는 리소스를 요청했다고 말해주는 것이다.

 

상태 코드	사유 구절	의미
400	Bad Request	클라이언트가 잘못된 요청을 보냈다고 말해준다.
401	Unauthorized	리소스를 얻기 전에 클라이언트에게 스스로를 인증하라고 요구하는 내용의 응답을 적절한 헤더와 함께 반환한다.
403	Forbidden	요청이 서버에 의해 거부되었음을 알려주기 위해 사용한다. 이 코드는 보통 서버가 거절의 이유를 숨기고 싶을 때 사용한다.
404	Not Found	서버가 요청한 URL을 찾을 수 없음을 알려주기 위해 사용한다. 종종 클라이언트 애플리케이션이 사용자에게 보여주기 위한 엔터티가 포함된다.
405	Method Not Allowed	요청한 URL에 대해, 지원하지 않는 메서드로 요청받았을 때 사용한다. 요청한 리소스에 대해 어떤 메서드가 사용 가능한지 클라이언트에게 알려주기 위해, 요청에 Allow 헤더가 포함되어야 한다.
407	Proxy Authentication Required	401 상태 코드와 같으나, 리소스에 대해 인증을 요구하는 프록시 서버를 위해 사용한다.
408	Request Timeout	클라이언트의 요청을 완수하기에 시간이 너무 많이 걸리는 경우, 서버는 이 상태 코드로 응답하고 연결을 끊을 수 있다. 이 타임아웃의 길이는 서버마다 다르지만 대개 어떠한 적법한 요청도 받아들일 수 있을 정도로 충분히 길다.
409	Conflict	요청이 리소스에 대해 일으킬 수 있는 몇몇 충돌을 지칭하기 위해 사용한다. 서버는 요청이 충돌을 일으킬 염려가 있다고 생각될 때 이 요청을 보낼 수 있다.
411	Length Required	서버가 요청 메시지에 Content-Length 헤더가 있을 것을 요구할 때 사용한다.
412	Precondition Failed	클라이언트가 조건부 요청을 했는데 그 중 하나가 실패했을 때 사용한다. 조건부 요청은 클라이언트가 Expect 헤더를 포함했을 때 발생한다.
413	Request Entity Too Large	서버가 처리할 수 있는 한계를 넘은 크기의 요청을 클라이언트가 보냈을 경우 사용한다.
414	Request URI Too Long	서버가 처리할 수 있는 한계를 넘은 길이의 요청 URL이 포함된 요청을 받은 경우 사용된다.
415	Unsupported Media Type	서버가 이해하거나 지원하지 못하는 내용 유형의 엔터티를 클라이언트가 보냈을 경우 사용한다.
416	Requested Range Not Satisfiable	요청 메시지가 리소스의 특정 범위를 요청했는데, 그 범위가 잘못되었거나 맞지 않을 때 사용한다.

 

3.4.5 500-599 : 서버 에러 상태 코드

 

때때로 클라이언트가 올바른 요청을 보냈음에도 서버 자체에서 에러가 발생하는 경우가 있다. 이것은 서버의 제한에 걸린 것일 수도 있고 혹은 게이트웨이 리소스와 같은 서버의 보조 구성요소에서 발생한 에러일 수도 있다.

 

상태 코드	사유 구절	의미
500	Internal Server Error	서버가 요청을 처리할 수 없게 만드는 에러를 만났을 때 사용한다.
501	Not Implemented	클라이언트가 서버의 능력을 넘은 요청을 했을 때 사용한다. ( ex. 서버가 지원하지 않는 메서드를 사용 )
502	Bad Gateway	프록시나 게이트웨이처럼 행동하는 서버가 그 요청 응답 연쇄에 있는 다음 링크로부터 가짜 응답에 맞닥뜨렸을 때 사용한다.
503	Service Unavailable	현재는 서버가 요청을 처리해 줄 수 없지만 나중에는 가능함을 의미하고자 할 때 사용한다. 만약 서버가 언제 그 리소스를 사용할 수 있게 될지 알고 있다면, 헤더에 Retry-After 를 포함 시킬 수 있다.
504	Gateway Timeout	상태 코드 408과 비슷하지만, 다른 서버에게 요청을 보내고 응답을 기다리다 타임아웃이 발생한 게이트웨이나 프록시에서 온 응답이라는 점이 다르다.
505	HTTP Version Not Supported	서버가 지원할 수 없거나 지원하지 않으려고 하는 버전의 프로토콜로 된 요청을 받았을 때 사용한다.

 

3.5 헤더

 

헤더에는 특정 종류의 메시지에만 사용할 수 있는 헤더와, 더 일반 목적으로 사용할 수 있는 헤더, 그리고 응답과 요청 메시지 양쪽 모두에서 정보를 제공하는 헤더가 있다. 헤더는 크게 5가지로 분류된다.

 

1. 일반 헤더 (General Headers)

일반 헤더는 클라이언트와 서버 양쪽 모두가 사용한다. 예를 들어, Date 혜더는 서버와 클라이언트를 가리지 않고 메시지가 만들어진 일시를 지칭하기 위해 사용하는 일반 목적 헤더이다. 양쪽 모두 사용할 것이다!

Date: Tue, 3 Oct 1974 02:16:00 GMT

 

2. 요청 헤더 (Request Headers)

이름에서 드러나는 것과 같이, 요청 헤더는 요청 메시지를 위한 헤더다. 그들은 서버에게 클라이언트가 받고자 하는 데이터 타입이 무엇인지 알려준다. 예를 들어, Accept 헤더가 있다.

아래는 어떤 요청도 다 받아들이겠다는 클라이언트의 메시지이다.

Accept: */*

 

3. 응답 헤더 (Response Headers)

응답 메시지는 클라이언트에게 정보를 제공하기 위한 자신만의 헤더를 갖고 있다. 예를 들어, 다음 헤더는 클라이언트에게 그가 Tiki-Hut 서버 1.0 버전과 대화하고 있음을 말해준다.

Server: Tiki-Hut/1.0

 

4. 엔터티 헤더 (Entity Headers)

엔터티 헤더란 엔터티 본문에 대한 헤더를 말한다. 예를 들어, 엔터티 헤더는 엔터티 본문에 들어있는 데이터 타입이 무엇인지 말해줄 수 있다. 예를 들어, 다음의 Content-Type 헤더는 애플리케이션에게 데이터가 iso-latin-1 문자 집합으로 된 HTML 문서임을 알려준다.

Content-Type: text/html; charset=iso-latin-1

 

5. 확장 헤더 (Extension Headers)

확장 헤더는 애플리케이션 개발자들에 의해 만들어졌지만 아직 승인된 HTTP 명세에는 추가되지 않은 "비표준헤더"다. HTTP 프로그램은 확장 헤더들에 대해 설령 그 의미를 모를지라도 전달해야할 필요가 있다.

 

 

3.5.1 일반 헤더

메시지에 대한 아주 기본적인 정보를 제공한다. 그들은 메시지가 어떤 종류이든 상관없이 유용한 정보를 제공한다. 예를 들어, 당신이 요청 메시지나 응답 메시지를 작성할 때, 요청에서나 응답에서나 메시지가 생성된 일시는 같은 의미를 가지므로, 이런 종류의 정보는 양쪽 메시지 헤더에 제공하는 것이 일반적이다.

 

헤더	설명
Connection	클라이언트와 서버가 요청/응답 연결에 대한 옵션을 정할 수 있게 해준다.
Date	메시지가 언제 만들어졌는지에 대한 날짜와 시간을 제공한다.
MIME-Version	발송자가 사용한 MIME의 버전을 알려준다.
Trailer chunked transfer	인코딩으로 인코딩된 메시지의 끝 부분에 위치한 헤더들의 목록을 나열한다.
Transfer-Encoding	수신자에게 안전한 전송을 위해 메시지에 어떤 인코딩이 적용되었는지 말해준다.
Upgrade	발송자가 '업그레이드'하길 원하는 새 버전이나 프로토콜을 알려준다.
Via	이 메시지가 어떤 중재자를 거쳐 왔는지 보여준다.

 

일반 캐시 헤더

HTTP/1.0은 HTTP 에플리케이션에게 매번 원 서버로부터 객체를 가져오는 대신 로컬 복사본으로 캐시할 수 있도록 해주는 최초의 헤더를 도입했다. 

 

Cache-Control

메시지와 함께 캐시 지시자를 전달하기 위해 사용한다.

 

3.5.2 요청 헤더 ( Request Header )

요청 메시지에서만 의미를 갖는 헤더이다. 누가 혹은 무엇이 그 요청을 보냈는지에 대한 정보나, 클라이언트의 선호나 능력에 대한 정보를 준다. 서버는 요청 헤더가 준 클라이언트에 대한 그 정보를 클라이언트에게 더 나은 응답을 주기 위해 활용할 수 있다.

 

헤더	설명
Client-IP	클라이언트가 실행된 컴퓨터의 IP를 제공한다.
From	클라이언트 사용자의 메일 주소를 제공한다.
Host	요청의 대상이 되는 서버의 호스트 명과 포트를 준다.
Referer	현재의 요청 URI가 들어있었던 문서의 URL을 제공한다.
User-Agent	요청을 보낸 애플리케이션의 이름을 서버에게 말해준다.
(Client Hint) UA-Color	클라이언트 기기 디스플레이의 색상 능력에 대한 정보를 제공한다.
UA-CPU	클라이언트 CPU의 종류나 제조사를 알려준다.
UA-Disp	클라이언트의 디스플레이(화면) 능력에 대한 정보를 제공한다.
UA-OS	클라이언트 기기에서 동작 중인 운영체제의 이름과 버전을 알려준다.
UA-Pixels	클라이언트 기기 디스플레이에 대한 픽셀 정보를 제공한다.

 

현재는 위와 같은 헤더 중에서 다르게 쓰이는 이름도 있는 것 같다. 그러나 중요한 키워드나 내용은 바뀌지 않으므로 참고해서 알아두자!

 

Accept 관련 헤더

 

클라이언트는 Accept 관련 헤더들을 이용해 서버에게 자신의 선호와 능력을 알려준다. 즉, 클라이언트가 뭘 원하는지 뭘 원하지 않는지 알려줄 수 있다. 서버는 이 추가 정보를 활용해서 무엇을 보낼 것인가에 대해 더 똑똑한 결정을 내릴 수 있다. 클라이언트는 그들이 원하는 것을 얻을 수 있으며, 서버는 클라이언트가 사용할 수 없는 것을 전송하는 데 시간과 대역폭을 낭비하지 않을 수 있다.

 

헤더	설명
Accept	서버에게 서버가 보내도 되는 미디어 종류를 말해준다.
Accept-Charset	서버에게 서버가 보내도 되는 문자 집합을 말해준다.
Accept-Encoding	서버에게 서버가 보내도 되는 인코딩을 말해준다.
Accept-Language	서버에게 서버가 보내도 되는 언어를 말해준다.
TE (Transfer-Encoding)	서버에게 서버가 보내도 되는 확장 전송 코딩을 말해준다.

 

조건부 요청 헤더

때때로, 클라이언트는 요청에 몇몇 제약을 넣기도 한다. 예를 들어, 클라이언트가 사본을 갖고 있는 상태라면, 서버에게 그 문서를 요청할 때 자신이 갖고 있는 사본과 다를 때만 전송해 달라고 요청하고 싶을 수 있다. 조건부 요청 헤더를 사용하면, 이러한 조건이 먼저 참인지 확인하게 하는 제약을 포함시킬 수 있다.

 

헤더	설명
Expect	클라이언트가 요청에 필요한 서버의 행동을 열거할 수 있게 해준다.
If-Match	문서의 엔터티 태그가 주어진 엔터티 태그와 일치하는 경우에만 문서를 가져온다.
If-Modified-Since	주어진 날짜 이후에 리소스가 변경되지 않았다면 요청을 제한한다.
If-None-Match	문서의 엔터티 태그가 주어진 엔터티 태그와 일치하지 않는 경우에만 문서를 가져온다.
If-Range	문서의 특정 범위에 대한 요청을 할 수 있게 해준다.
If-Unmodified-Since	주어진 날짜 이후에 리소스가 변경되었다면 요청을 제한한다.
Range	서버가 범위 요청을 지원한다면, 리소스에 대한 특정 범위를 요청한다.

 

요청 보안 헤더

 

HTTP는 자체적으로 요청을 위한 간단한 인증요구/응답 체계를 갖고 있다. 그것은 요청하는 클라이언트가 어느 정도의 리소스에 접근하기 전에 자신을 인증하게 함으로써 트랜잭션을 약간 더 안전하게 만들고자 한다. 우리는 인증요구/응답 체계에 대해, HTTP 위에서 구현된 다른 보안 체계들과 함께 14장에서 다룰 것이라 한다!

 

헤더	요청
Authorization	클라이언트가 서버에게 제공하는 인증 그 자체에 대한 정보를 담고 있다.
Cookie	클라이언트가 서버에게 토큰을 전달할 때 사용한다. 진짜 보안 헤더는 아니지만, 보안에 영향을 줄 수 있다는 것은 확실하다.

 

프락시 요청 헤더

인터넷에서 프락시가 점점 흔해지면서, 그들의 기능을 돕기 위해 몇몇 헤더들이 정의되어 왔다.

 

헤더	설명
Max-Forwards	요청이 원 서버로 향하는 과정에서 다른 프락시나 게이트웨이로 전달될 수 있는 최대 횟수. TRACE 메서드와 함께 사용된다.
Proxy-Authorizatin	Authorization과 같으나 프락시에서 인증을 할 때 쓰인다.
Proxy-Connection	Connection과 같으나 프락시에서 연결을 맺을 때 쓰인다.

 

 

3.5.3 응답 헤더 ( Response Header )

 

응답 헤더는 클라이언트에게 부가 정보를 제공한다. 누가 응답을 보내고 있는지 혹은 응답자의 능력은 어떻게 되는지 알려주며, 더 나아가 응답에 대한 특별한 설명도 제공할 수 있다. 이 헤더들은 클라이언트가 응답을 잘 다루고 나중에 더 나은 요청을 할 수 있도록 도와준다.

 

헤더	설명
Age	응답이 얼마나 오래되었는지 {응답이 중개자 (프락시 캐시 등등) 에서 왔음을 암시한다}
Public	서버가 특정 리소스에 대해 지원하는 요청 메서드의 목록
Retry-After	현재 리소스가 사용 불가능한 상태일 때, 언제 가능해지는지 날짜 혹은 시각
Server	서버 애플리케이션의 이름과 버전
Title	HTML 문서에 주어진 것과 같은 제목
Warning	사유 구절에 있는 것보다 더 자세한 경고 메세지

 

협상 헤더

 

서버에 프랑스어와 독일어로 번역된 HTML 문서가 있는 경우와 같이 여러 가지 표현이 가능한 상황이라면, HTTP/1.1은 서버와 클라이언트가 어떤 표현을 택할 것인가에 대한 협상을 할 수 있도록 지원한다.

 

헤더	설명
Accept-Ranges	서버가 지원에 대해 받아들일 수 있는 범위의 형태
Vary	서버가 확인해 보아야 하고 그렇기 때문에 응답에 영향을 줄 수 있는 헤더들의 목록 ex) 서버가 클라이언트에게 보내줄 리소스의 가장 적절한 버전을 선택하기 위해 살펴보아야 하는 헤더들의 목록

 

응답 보안 헤더

 

기본적으로 HTTP 인증요구/응답 체계에서 응답 측에 해당하는 요청 보안 헤더는 이미 본 적이 있을 것이다. 

 

헤더	설명
Proxy-Authenticate	프락시에서 클라이언트로 보낸 인증요구의 목록
Set-Cookie	진짜 보안 헤더는 아니지만, 보안에 영향은 줄 수 있다. 서버가 클라이언트를 인증할 수 있도록 클라이언트 측에 토큰을 설정하기 위해 사용한다.

 

3.5.4 엔터티 헤더 ( Entity Header )

 

HTTP 메시지의 엔터티에 대해 설명하는 헤더들은 많다. 요청과 응답 양쪽 모두 엔터티를 포함할 수 있기 때문에, 이 헤더들은 양 타입의 메시지에 모두 나타날 수 있다. 엔터티 헤더는 엔터티와 그것의 내용물에 대한, 개체의 타입부터 시작해서 주어진 리소스에 대해 요청할 수 있는 유효한 메서드까지, 광범위한 정보를 제공한다.

일반적으로 엔터티 헤더는 메시지의 수신자에게 자신이 다루고 있는 것이 무엇인지 말해준다.

 

헤더	설명
Allow	이 엔터티에 대해 수행될 수 있는 요청 메서드들을 나열한다.
Location	클라이언트에게 엔터티가 실제로 어디에 위치하고 있는지 말해준다. 수신자에게 리소스에 대한 위치(URL)을 알려줄 때 사용한다.

 

콘텐츠 헤더

 

콘텐츠 헤더는 엔터티의 콘텐츠에 대한 구체적인 정보를 제공한다. 콘텐츠의 종류, 크기, 기타 콘텐츠를 처리할 때 유용하게 활용될 수 있는 것들이다. 예를 들어, 웹브라우저는 내용 유형을 기술한 Content-Type 헤더를 보고 그 객체를 어떻게 보여줄 지 결정할 수 있다.

 

헤더	설명
Content-Base	본문에서 사용된 상대 URL을 계산하기 위한 기저 URL
Content-Encoding	본문에 적용된 어떤 인코딩
Content-Language	본문을 이해하는데 가장 적절한 자연어
Content-Length	본문의 길이나 크기
Content-Location	리소스가 실제로 어디에 위치하는지
Content-Range	전체 리소스에서 이 엔터티가 해당하는 범위를 바이트 단위로 표현
Content-Type	이 본문이 어떤 종류의 객체인지

 

엔터티 캐싱 헤더

 

일반 캐싱 헤더는 언제 어떻게 캐시가 되어야 하는지에 대한 지시자를 제공한다. 엔터티 캐싱 헤더는 엔터티 캐싱에 대한 정보를 제공한다. 예를 들면, 리소스에 대해 캐시된 사본이 아직 유효한지에 대한 정보와, 캐시된 리소스가 더 이상 유효하지 않게 되는 시점을 더 잘 추정하기 위한 단서 같은 것이다.

 

헤더	설명
Expires	이 엔터티가 더 이상 유효하지 않아 원본을 다시 받아와야 하는 일시
Last-Modified	가장 최근 이 엔터티가 변경된 일시