3.1 메시지의 흐름
HTTP 메시지는 HTTP 앱들간에 주고받은 데이터의 블록들이다. 이 데이터의 블록들은 내용과 의미를 설명하는 텍스트 메타정보로 시작하고, 선택적으로 데이터가 올 수 있다.
메시지는 클라이언트, 서버, 프록시 사이를 흐른다. 이때 메시지의 각 방향을 의미하는 '인바운드' 아웃바운드' '업스트림' 다운스트림' 의 용어들이 존재한다.
1. 원 서버 방향을 인바운드로 하여 송신
HTTP의 인바운드는 메시지가 원 서버로 향하는 것을 의미하고, 모든 처리가 끝난 뒤 메시지가 클라이언트에게 돌아오는 것을 아웃바운드로 이동한다 라고한다.
2. 다운스트림으로 흐르는 메시지
모든 HTTP 메시지는 강물같이 흘러, 발송자는 수신자의 업스트림, 수신자는 발신자의 다운스트림이다. 즉 모든 HTTP 메시지는 종류에 상관없이 다운스트림으로 흐른다.
3.2 메시지의 각 부분
HTTP 메시지는 단순한, 데이터의 구조화된 블록으로, 시작줄 , 헤더 블록, 본문 이렇게 세 부분으로 이루어진다.
시작줄은 어떤 메시지인지, 헤더블록은 속성을, 본문은 데이터를 담고 있고, 본문은 없을 수도 있다.
시작줄과 헤더블록은 줄 단위로 구분되고, 각 줄은 줄바꿈 문자열로 구분된다. 이를 CRLF(Carriage Return + Line Feed)라고 한다.
본문은 단순히 선택적인 데이터 덩어리로서 텍스트, 이진데이터를 포함할 수 있다. 헤더는 본문에 대한 많은 정보를 담고있다.
1. 메시지 문법
모든 HTTP 메시지는 요청 응답 메시지로 분류되고 기본적으로 구조가 동일하다.
요청 :
<메서드> <요청 URL> <버전>
<헤더>
<엔터티 본문>
응답 :
<버전> <상태코드> <사유 구절>
<헤더>
<엔터티 본문>
메서드 : 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작. 한단어로 미리 정의 되어있다.
요청 URL : 요청 리소스를 지칭하는 완전한 URL 혹은 URL의 경로 구성요소.
버전 : 메시지에서 사용중인 HTTP의 버전. HTTP/<메이저>.<마이너> 의 형식
상태 코드 : 요청 중 일어난 일을 설명하는 세자리의 숫자.
사유 구절(reason-phrase) : 오로지 사람에게 읽히기 위한 목적으로, 상태코드의 의미를 설명하는 짧은 문구.
헤더들 : 이름, 콜론(:), 선택적 공백, 값, CRLF 의 헤더가 0 개이상 나타나는 부분. 보통은 빈 내용의 CRLF로 끝나면 헤더의 끝을 지칭한다.
엔터티 본문 : 임의의 데이터 블록을 포함. 본문이 없을경우 CRLF로 메시지가 끝나지만, 많은 경우 규칙을 지키지않아 CRLF로 끝나지 않는 경우도 있다.
2. 시작줄
요청줄 : 동작을 설명하는 메서드, 대상을 지칭하는 URL, 사용중인 HTTP 버전을 포함한다.
모든 필드는 공백으로 구분된다.
응답줄 : 숫자로 된 상태코드, 수행 상태를 설명하는 사유 구절, HTTP 버전을 포함한다.
모든 필드는 공백으로 구분된다.
메서드 ::
- GET : 서버에 어떤 문서를 가져온다. | 본문 X
- HEAD : 서버에서 어떤 문서에 대해 헤더만 가져온다. | 본문 X
- POST : 서버가 처리해야 할 데이터를 보낸다. | 본문 O
- PUT : 서버에 요청 메시지의 본문을 저장한다. | 본문 O
- TRACE : 메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다. | 본문 X
- OPTIONS : 서버가 어떤 메서드를 수행할 수 있는지 확인한다. | 본문 X
- DELETE : 서버에서 문서를 제거한다. | 본문 X
이외에도 HTTP를 확장시켜 메서드를 추가로 구현해, 확장메서드를 사용 가능하다.
상태 코드 ::
| 전체 범위 | 정의된 범위 | 분류 |
| 100~199 | 100~101 | 정보 |
| 200~299 | 200~206 | 성공 |
| 300~399 | 300~305 | 리다이렉션 |
| 400~499 | 400~415 | 클라이언트 에러 |
| 500~599 | 500~505 | 서버 에러 |
프로토콜이 진화하면서 더 많은 상태코드가 정의 될 수있다.
사유구절 ::
사유구절은 상태코드와 일대일 대응이고, 애플리케이션 개발자가 사용자에게 요청중에 무슨일이 일어났는지 알려주기 위해 넘겨줄 수 있는 설명이다. 상태 코드의 사람이 이해하기 쉬운버전이다.
아무런 규칙도 없고, 상태 코드의 올바른 설명이면 충분하다.
버전 번호 ::
HTTP/x.y 의 형식으로 요청과 응답 메시지 양쪽에 모두 기술된다. HTTP를 사용하는 앱의 능력과 메시지 형식에 대한 단서를 제공하기 위함이다. 이때 버전은 메시지를 보낸 앱이 이해할 수 있는 가장 높은 버전을 가르킨다.
3. 헤더
헤더 필드는 요청과 응답 메시지에 추가 정보를 더하고, 이는 기본적으로 이름/값 쌍의 목록이다.
헤더 분류 ::
- 일반 헤더 : 요청과 응답 양쪽에 나타날 수 있음
- 요청 헤더 : 요청에 대한 부가 정보를 제공
- 응답 헤더 : 응답에 대한 부가 정보를 제공
- Entity 헤더 : 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 서술
- 확장 헤더 : 명세에 정의되지 않은 새로운 헤더
ex) DATE: Tue, 3 Oct 1997 02:16:03 GMT // 서버가 응답을 만들어 낸 시각
Content-length: 15040 // 15040바이트의 데이터를 포함한 엔터티 본문
헤더를 여러줄로 나누기:
긴 헤더줄은 여러 줄로 쪼개 읽기 좋게 만들수 있는데, 이때 추가 줄 앞에 최소 하나의 스페이스 혹은 탭 문자가 와야 함.
4. 엔터티 본문
엔터니 본문은 메시지의 화물로서, 이미지 비디오 html문서 소프트웨어 어플리케이션, 신용카드 트랜잭션, 전자우편 등 여러 종류의 디지털 데이터를 실어 나를수 있다.
3.3 메서드
모든 서버가 모든 메서드를 구현하지 않는다. 또한 메서드는 대부분 제한적으로 사용된다. 아무나 서버에 지정된 리소스를 DELETE, PUT 과같이 변경하길 바라질 않는다.
1. 안전한 메서드(SAFE METHOD)
HTTP는 안전한 메서드라 불리는 메서드의 집합을 정의한다. GET, HEAD 메서드와 같이 HTTP요청의 결과로 서버에 어떤 작용도 없는 메서드를 안전한 메서드라고 정의한다.
안전한 메서드를 정의하는 이유는 안전하지 않은 메서드가 사용될 때, 서버에서 특정한 '작용'이 일어남을 사용자에게 알려주기 위함이다.
2. GET
가장 흔히 쓰이는 메서드로, 서버에게 리소스를 달라고 요청하기 위해 쓰인다. HTTP/1.1은 서버가 이 메서드를 구현할것을 요구한다.
3. HEAD
정확히 GET메서드 처럼 행동하지만, 서버는 응답으로 헤더만 돌려준다. 엔티티 본문은 결코 반환되지 않는다.
HEAD를 사용하면,
- 리소스를 가져오지 않고도 리소스에 대한 정보를 알 수 있다.
- 응답 상태코드를 통해 개체가 존재하는지 알 수 있다.
- 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.
서버 개발자들은 HEAD의 결과와, GET결과의 헤더와 정확히 동일해야 함을 보장해야한다.
4. PUT
PUT을 이용해 서버에 문서를 직접 쓸 수 있다. 서버가 PUT요청을 받으면, 요청 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL 문서가 존재한다면 본문을 사용해서 교체한다.
PUT은 콘텐츠를 변경할 수 있기 때문에, 웹서버는 클라이언트에게 로그인을 요구한다.
5. POST
POST는 서버에 입력 데이터를 전송하기 위해 설계되었다. 흔히 HTML폼을 지원하기 위해 사용된다. 채워진 폼에 담긴 데이터는 서버에 전송되어, 서버는 이를 모아서 필요로 하는 곳(EX 데이터를 처리할 서버 게이트 프로그램)에 보낸다.
6. TRACE
클라이언트의 요청메시지는 방화벽, 프락시, 게이트웨이 등 여러 앱들을 통해 서버에 전달되고, 각 앱에서는 HTTP 요청을 수정 가능하다. 따라서 TRACE메서드는 요청이 서버에 도착했을때, '루프백'(LOOPBACK) 진단을 시작해 클라이언트에서 서버까지 HTTP요청이 어떻게 변화했는지를 본문에 갱신하면서 응답한다.
하지만 많은 HTTP앱이 메서드에 따라 다르게 동작하기 때문에, TRACE요청에 어떤 메서드의 경로를 TRACE할지는 일반적으로 중간 앱이 결정을 내린다.
7. OPTION
웹서버에게 여러 가지 종류의 지원 범위에 대해서 물어본다. 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어보고, 이를 통해 리소스에 접근하지 않고, 어떻게 접근하는 것이 최선인지 판단할 수 있다.
8. DELETE
서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청한다. 하지만 서버는 클라이언트의 요청을 무시할 수 있는 HTTP명세가 있기때문에, 삭제의 수행이 보장되지는 않는다.
9. 확장 메서드
서버의 리소스에 대한 관리능력을 확장하는 수단으로 확장 메서드를 사용한다.
대표적인 예로
LOCK : 사용자가 리소스를 잠궈 다른 사용자가 접근하지 못하도록한다.
MKCOL : 사용자가 문서를 생성할 수 있도록한다.
COPY : 서버의 리소스를 복사한다.
MOVE : 서버의 리소스를 옮긴다.
프록시는 종단간 행위를 망가뜨리지 않는다면, 알려지지 않은 메서드가 담긴 메시지를 다운스트림 서버로 전달하려고 시도한다. 확장 메서드에 대해서는 관용적으로 받아들이고, 엄격하게 메시지를 보내는 오랜 규칙을 따르는 것이 좋다.
3.4 상태 코드
1. 100-199: 정보성 상태 코드
정보성 상태 코드는 HTTP/1.1에 도입되었다.
100 | Continue | 요청의 시작부분 일부가 받아들여졌으며, 클라이언트는 나머지를 이어서 보내야 함을 의미하고, 서버는 요청을 받아 응답해함을 의미한다.
101 | Swiching Protocols | 클라이언트가 UPGRADE 헤더에 나열한 것 중 하나로 서버가 프로토콜을 바꾸었음을 의미한다.
클라이언트와 100 CONTINUE :
클라이언트가 서버에게 엔터티를 보내려고하고, 그전에 100-CONTINUE 응답을 기다리려고한다면, 값을 100-CONTNUE 로하는 EXPECT 요청헤더를 서버에게 보낼 필요가 있다. 100-CONTINUE EXPECT 헤더를 보내고 엔터티를 보내지 않는다면, 서버는 혼란에 빠진다.
이는 여러 측면의 최적화를 위한 것이고, 클라이언트는 서버가 다루거나 사용할 수 없는 큰 엔터티를 보내지 않으려는 목적으로 사용해야 한다.
서버와 100 CONTINUE :
서버가 100 CONTINUE 값이 담긴 요청을 받는다면, 100 CONTINUE 응답 혹은 에러 코드로 답해야 한다. 서버는 100 CONTINUE 응답을 받을 것을 의도하지 않은 클라이언트에게 100 CONTINUE 상태코드를 절대 보내서는 안된다. 이것 또한 클라이언트에게 혼란을 줄 수있다. 100 CONTINUE 응답을 보내기 전에 클라이언트에게서 요청을 받았다면, 100 CONTINUE 응답은 생략가능하지만, 요청에대한 응답은 반드시 필요하다. 마지막으로, 100 CONTINUE 응답을 받을 것을 의도한 요청(클라이언트)을 받고 난 상태에서 엔터티 본문을 읽기 전에 요청을 끝내기로 결정했다면, 서버는 그냥 응답을 보내고 연결을 닫아서는 안된다.(4장에 'TCP 끊기와 리셋 에러' 참고)
프락시와 100 CONTINUE : 클라이언트로부터 100 COTNINUE 응답을 의도한 요청(EXPECT)를 받은 프락시는 다음 홉(NEXT-HOP)서버가 HTTP/1.1을 따르거나, 모른다면 EXPECT 헤더를 포함시켜 요청을 전달하고, 아니라면 417 EXPECTAION FAILED 에러로 응답해야한다. 만일 프락시가 HTTP/1.0이전 버전의 클라이언트를 대신해 EXPECT 100 CONTINUE 요청을 포함시키로 결정한다면, 클라이언트에게 100 CONTINUE 응답을 클라이언트로 전달해서는 안된다.
2. 200-299 : 성공 상태코드
| 상태 코드 | 사유 구절 | 의미 |
| 200 | OK | 요청은 정상이고, 본문에 요청한 리소스를 포함하고 있음. |
| 201 | CREATED | 개체 생성 요청에 대한 응답. 생성된 리소스에 관한 구체적인 참조가 담긴 LOCATION 헤더와 함께, 리소스를 참조할 수 있는 여러 URL을 엔터티 본문에 포함해야 한다. 서버는 상태코드를 보내기 이전에 반드시 객체를 생성해야 한다. |
| 202 | ACCEPTED | 요청은 받아들여졌는데, 서버는 아직 어떠한 동작도 수행하지 않았다. 서버가 요청을 완료할 것인지에 대한 보장은 없다. 단지 요청이 적합하다는 의미이다. 서버는 본문에 요청이 언제 완료될 것인지에 대한 추정을 포함 해야한다. |
| 203 | NON-AUTHORIATIVE INFORMATION | 본문에 들어있는 정보가 원래 서버가 아닌 리소스 사본에서 온것임을 의미한다. |
| 204 | NO CONTENT | 엔터티 본문을 포함하지 않는다. 주로 웹 브라우저를 새 문서로 이동시키지 않고 갱신하고 자할때에 사용한다(ex 폼 리프레시) |
| 205 | RESET CONTETNT | 주로 브러우저를 위해 사용되는 또 하나의 코드로, 현재 페이지에 있는 HTML폼에 채워진 모든 값을 비우라고 말한다. |
| 206 | PARTIAL CONTENT | 부분 혹은 범위 요청이 성공했다. 클라이언트가 특별한 헤더를 이용해서 문서의 부분 혹은 특정 범위를 요청할때 요청이 성공될 때 사용되고, 206응답은 Content-Range 와 Date 헤더를 반드시 포함해야하고, Etag와 Content-Location중 하나의 헤더도 반드시 포함해야 한다. |
3. 300-399 : 리다이렉션 상태 코드
리 다이렉션 상태 코드는 클라이언트의 관심 리소스에 대해 리소스를 찾을 수 있는 다른 위치를 사용하라고 말하거나, 그 리소스 내용 대신 다른 대안 응답을 제공한다. 다른 위치를 알려주기 위해, 리다이렉션 코드와 location헤더를 포함 할 수 있다. HEAD가 아닌 요청에 대해 리다이렉션 코드를 응답할 때, URL에 대한 링크를 포함시키는 것이 좋은 습관이다.
| 상태 코드 | 사유 구절 | 의미 |
| 300 | Multiple Choice | 클라이언트가 동시에 여러 리소르를 가르키는 URL을 요청한 경우 |
| 301 | Moved Permanently | 요청한 URL이 옮겨졌을 때 사용한다. 응답 LOCATION 헤더에 현재 리소스가 존재하는 URL을 포함해야한다. |
| 302 | Found | 301과 동일하다. 그러나 클라이언트는 LOCATION헤더의 URL을 임시로 사용해야 하고 이후에는 원래 URL을 사용해야 한다. |
| 303 | See Other | 리소스를 다른 URL에서 가져와야 한다고 말해주고자 사용한다. 새URL은 LOCATION 헤더에 존재하고, POST 요청에 대한 응답으로 클라이언트에게 리소스의 위치를 알려주기 위해 사용된다. |
| 304 | Not Modified | 헤더를 이용해 조건부 요청을 만들어, 리소스 변경 사항이 있는지 요청할때, 이 코드는 수정되지 않았음을 의미하고 본문을 포함해서는 안된다. |
| 305 | Use Proxy | 리소스가 반드시 프록시를 통해서 접근 되어야 함을 의미한다. 프락시의 위치는 LOCATION 헤더에 주어지고, 클라이언트와 서버 모두 특정 리소스에 대한 것이라고 해석한다. |
| 306 | (not use) | |
| 307 | Temporary Redirect | 301 상태 코드와 비슷하지만, LOCATION헤더로 주어진 URL을 임시목적으로 사용해아 한다. |
HTTP/1.0 과 1.1 버전간 상태코드의 의미가 조금 다르기 때문에 301, 302, 307을 버전에 맞게 잘 구별하여 사용해야 한다.
4. 400-499: 클라이언트 에러 상태 코드
| 상태 코드 | 사유 구절 | 의미 |
| 400 | Bat Request | 잘못된 요청을 보냄 |
| 401 | Unauthorized | 리소스를 얻기전 클라이언트에게 인증을 요청한다. |
| 402 | Payment Required | 아직은 쓰이지 않지만, 미래에 사용될 가능성에 준비되었다. |
| 403 | Forbidden | 서버에 의해 거부되었음. 그 이유를 서버는 본문에 포함 시킬 수 있다. |
| 404 | Not Found | 요청한 URL을 찾을 수 없을 때 사용한다. |
| 405 | Method Not Allowed | 지원하지 않는 메소드를 요청 받았을때. |
| 406 | Not Acceptable | 매개변수로 클라이언트의 받을 수 있는 엔터티 종류를 표시할 수 있는데, 서버의 리소스 중 클라이언트가 받을 수 있는 리소스가 없을 때. |
| 407 | Proxy Authertication Required | 프락시 서버의 401 이다. |
| 408 | Request Timeout | 요청수행에 시간이 너무 많이 걸리는 경우, 응답하고 연결을 끊을 수 있다. |
| 409 | Conflict | 요청이 리소스에 대해 충돌을 일으킬 염려가 있을때. |
| 410 | Gone | 한때 서버에 리소스가 있었지만, 없어진 경우. |
| 411 | Length Required | 요청에 Content-Length 필요한데 없을 경우. |
| 412 | Precondition Failed | 조건부 요청중 하나가 실패 했을 때. |
| 413 | Request Entity Too Lagre | 요청 크기가 너무 클때. |
| 414 | Request URI Too Long | 요청 URL이 너무 클때. |
| 415 | Unsupported Media Type | 서버의 지원 엔터티를 넘어설 때 |
| 416 | Requested Range Not Satisfiable | 리소스의 특정 범위를 요청할 때 그 범위가 맞지않을 경우 |
| 417 | Expectation Failed | Expect요청 헤더에 서버가 만족시킬 수 없을 경우 |
5. 500-599 : 서버 에러 상태 코드
| 상태 코드 | 사유 구절 | 의미 |
| 500 | Internal Server Error | 내부적으로 요청을 처리 할 수 없을 때. |
| 501 | Not Implemented | 서버의 능력 밖의 요청을 할 때. |
| 502 | Bad GateWay | 프락시나 게이트 웨이처럼 행동하는 서버가 다음 링크로부터 가짜 응답에 맞닥뜨렷을 때. |
| 503 | Service Unavailable | 요청의 처리가 지금은 불가능하지만, 나중에 가능함을 의미함. Retry-After 헤더에 언제 가능할지 포함시킬수 있다. |
| 504 | Gateway Timeout | 다른 서버에 요청을 보내고 프락시나 게이트웨이에서 온 Timeout |
| 505 | HTTP Version Not Supported | 지원하지 않는 버전의 프로토콜 요청을 받았을 때 |
3.5 헤더
일반헤더(General Headers) : 클라이언트 , 서버 양쪽모두가 사용하는 헤더로, 다양한 목적으로 사용됨. 예를들어 Date 헤더
요청 헤더(Reqeust Headers) : 클라이언트가 받고자 하는 데이터의 부가정보.
응답 헤더(Response Headers) : 클라이언트에게 정보를 제공하기 위한 자신만의 헤더.
엔터티 헤더(Entity Headers) : 본문에 대한 헤더.
확장 헤더(Extension Headers) : 비표준 헤더.
1. 일반 헤더
Connection :
클라이언트와 서버가 요청/응답 연결에 대한 옵션을 정할 수 있음
Date :
메시지의 생성 날짜 시각
MINE-Version :
발송자의 MINE 버전
Trailer chunked transfer :
인코딩으로 인코딩된 메시지의 끝부분에 위치한 헤더들의 목록(15장 '청크와 지속 커넥션' 참조)
Transfer-Encoding :
수신자에게 메시지 인코딩 방식을 전달함
Upgrade :
발송자가 '업그레이드'하길 원하는 새 버전이나 프로토콜을 알려줌
Via :
메시지가 어떤 중계자(프락시,게이트웨이)를 통해 왔는지 알려줌.
# 일반 캐시 헤더
로컬 복사본으로 캐시할 수 있도록 해주는 최초의 헤더.
Cache-Control : 메시지와 캐시 지시자를 전달함
Pragma : 잘 안사용하고, 더이상 쓰이지 않음
2. 요청 헤더
Client-IP :
클라이언트 컴퓨터 IP
From :
클라이언트 사용자의 메일 주소
Host :
요청의 대상이 되는 서버의 호스트, 포트
Referer :
요청 URI가 들어있는 문서의 URL
UA-Color :
클라이언트 디스플레이 색상 능력
UA-CPU :
클라이언트 CPU 종류 및 제조사
UA-Disp :
클라이언트 디스플레이 능력
UA-OS :
클라이언트 운영체제 이름, 버전
User-Agent :
요청 애플리케이션의 이름
# Accept 관련 헤더
클라이언트는 서버에게 자신의 선호와 능력을 Accept 헤더를 통해 알려줌.
Accept : 서버가 보내도 되는 미디어 종류
Accept-Charset : 문자집합
Accept-Encoding : 클라이언트의 가능한 인코딩
Accept-Language : 언어
TE : 확장 전송 코딩(15장 'Transfer-Encoding 헤더' 참조)
# 조건부 요청 헤더
클라이언트는 요청에 조건을 달아 리소스를 요청함. 서버에게 요청에 응답전 리소스의 조건을 따지고 보내달라는 헤더를 씀.
Expect :
요청에 필요한 서버의 해동을 열거
If-Match :
엔터티 태그가 주어진 엔터티 태그와 일치할 때
If-Modified-Since :
주어진 날 이후 리소스가 변경되지 않았다면 요청을 제한함.(안바뀌면 갖고오지마라)
If-None-Match :
엔터티 테그가 엔터티 태그와 불일치 할때.
If-Range :
문서의 특정 범위에 대한 요청할 때.
If-Unmodified-Since :
바꼈다면 요청을 제한함.(바뀌면 갖고오지 마라)
Range :
리소스 특정 범위를 요청
#요청 보안 헤더
요청자를 인증하게 함으로 트랜잭션을 안전하게 만듬.
Authorization : 서버에게 제공하는 인증 그 자체 정보
Cookie : 서버에게 토큰을 전달할 때(11장 참고)
Cookie2 : 쿠키의 버전을 알려줄 때.
#프락시 요청 헤더
프락시의 기능을 돕기 위한 헤더.
Max-Forwards : 다른 중간 서버로 전달 할 수 있는 최대 횟수.
Proxy-Authorization : 프락시에서 인증
Proxy-Connection : 프락시에서 연결을 맺을 때.
3. 응답 헤더
각각 응답에 따른 응답 헤더를 갖는다. 응답자가 누군지, 능력, 등등
Age : 응답이 얼마나 오래 되었는지
Public : 특정 리소스에 지원하는 메소드 목록
Retry-After : 사용 불가능한 상태일때, 가능해지는 날짜 혹은 시간
Server : 서버 애플리케이션 이름, 버전
Title : HTML문서에서의 제목
Warning : 자세한 경고 메세지
# 협상 헤더
요청이 여러개의 리소스를 가르킬 때, 협상을 지원한다.
Accept-Ranges : 서버가 자원에 대해 받아 들일수 있는 범위와 형태
Vary : 서버가 확인 해봐야할 헤더 목록, 클라이언트에게 보내줄 리소스의 적절한 버전을 찾기 위해.
# 응답 보안 헤더
Proxy-Autherticate : 프락시에서 클라이언트로 보낸 인증요구 목록
Set-Cookie : 진짜 보안 헤더는 아님, 서버가 클라이언트를 인증할 수 있도록 클라이언트 측에 토큰을 설정하기 위해.
Set-Cookie2: 비슷함
WWW-Authenticate : 서버에서 클라이언트로 보낸 인증요구의 목록
4. 엔티티 헤더
수신자에게 다루고 있는것이 무엇인지에 대한 정보.
Allow : 엔터티에 대해 수행될 수 있는 요청 메서드의 목록
Location : 엔터티가 실제로 어디에 위치하는지 또는 리소스에 대한 위치를 알려줄 때.
#콘텐츠 헤더
Content-Base : 상대 URL위한 기저 URL
Content-Encoding : 본문의 인코딩 방식
Content-Language : 자연어
Content-Length : 본문 길이나 크기
Content-Location : 리소스의 실제 위치
Content-MD5 : 본문의 MD5 체크섬(checksum 전송상 에러를 막기위함)
Content-Range : 리소스에서 엔터티의 범위를 바이트 단위로 표현
Content-Type : 본문의 종류
# 엔터티 캐싱 헤더
리소스에 캐싱된 사본이 유효한지 여부 등.
ETag : 엔터티에 대한 엔터티 태그
Expires : 엔터티가 더이상 유효하지 않아 원본을 다시 받아와야 하는 일시
Last-Modified : 가장 엔터티가 변경된 일시
3.6 추가 정보
http://www.w3.org/Protocols/rfc2616rfc2616.txt
HTTP Pocket Reference
Http를 위한 w3c 아키텍처 페이지
'독서 리마인더 > HTTP 완벽가이드' 카테고리의 다른 글
| [HTTP 완벽가이드] 2장 URL과 리소스 (1) | 2021.04.29 |
|---|---|
| [HTTP 완벽가이드] 1장 HTTP : 웹의 기초 (0) | 2021.04.28 |