HTTP란 무엇인가?

URI(Uniform Resource Identifiers)

스키마를 나타내는 리소스를 식별하기 위한 식별자.

스키마는 리소스를 얻기 위한 수단에 이름을 붙이는 방법이다. 공식 URI 스키마는 ICANN 산하 조직인 IANA에 등록되어 있다.

URL(Uniform Resource Locator)

리소스의 장소(네트워크 상의 위치)를 나타낸다. URL은 URI의 서브셋이다.

절대적 위치를 나타내는 URL과 상대적 위치를 나타내는 상대 URL이 있다.

http://user:pass@www.example.com:80/dir/index.html?uid=1#ch1

http, https 같은 스키마를 사용하여 리소스를 얻기 위해 사용하는 프로토콜을 명시한다. 대문자, 소문자는 무시되고 마지막에 :문자가 붙는다. data:와 javascript:와 같은 데이터와 프로그램을 지정할 수도 있다.

user:pass는 자격정보를 나타내는데 서버로부터 리소스를 취득하기 위해 Credential이 필요할 경우 지정할 수 있다.

www.example.com은 서버 주소로 도메인 명이나 192.168.1.1과 같이 IPv4 주소나 [0:0:0:0:0:0:0:1]과 같이 IPv6 주소를 명시할 수 있다.

서버 포트를 지정할 수 있는데 생략하면 기본 포트가 사용된다.

/dir/index.html은 특정 리소스를 식별하기 위해 서버 상의 경로를 지정한다.

지정된 리소스에 임의의 파라미터를 넘겨주기 위해 쿼리 문자열을 사용할 수 있다.

#ch1은 프래그맨트 식별자 인데, 주로 취득한 리소스에서 서브 리소스를 가리키기 위해서 사용된다.

HTTP

HTTP는 클라이언트와 서버 간에 통신을 한다. 리소스를 요청하는 쪽이 클라이언트가 되고 리소스를 제공하는 쪽이 서버가 된다. 반드시 클라이언트 측으로부터 통신이 시작된다. 요청 없이 리스폰스를 송신하는 일은 없다.

Stateless

HTTP는 상태를 계속 유지하지 않는 Stateless 프로토콜이다. HTTP 프로토콜 레벨에서는 이전에 보냈던 리퀘스트나 이미 되돌려준 리스폰스에 대해서는 전혀 기억하지 않는다. 이는 많은 데이터를 매우 빠르고 확실하게 처리하는 Scalability를 확보하기 위해서 이와 같이 간단하게 설계되어 있다.

상태를 계속 유지하고 싶은 요구에 부응하기 위해 Cookie라는 기술이 도입됐다.

Method

메서드는 대문자와 소문자를 구별하기 때문에 대문자로 써야 한다.

• GET
  • 리소스를 가져올 수 있도록 요구한다.
• POST
  • 엔티티를 전송한다.
• PUT
  • 파일을 전송한다.
• HEAD
  • 메시지 헤더를 요청한다. GET과 같은 기능이지만 메시지 바디는 돌려주지 않는다.
  • URI 유효성과 리소스 갱신 시간을 확인하는 목적 등으로 사용된다.
• DELETE
  • 파일 삭제에 사용된다.
• OPTIONS
  • 제공하고 있는 메서드를 조사하기 위해 사용된다.
• CONNECT
  • 프록시에 터널 접속을 확립을 요청해서 TCP 통신을 터널링 하기 위해 사용된다.
  • 주로 SSL과 TLS 등의 프로토콜로 암호화된 것을 터널링 시키기 위해 사용된다.

지속 연결(Persistent Connections)

HTTP 초기 버전에서는 HTTP 통신을 한 번 할 때마다 TCP에 의해 연결과 종료를 했다. 매번 연결하고 종료하는 낭비가 늘어나서 지속 연결(Persistent Connections)이라는 방법이 나왔다.

어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지한다.

지속 연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인화를 가능하게 한다. 파이프라인화에 의해서 이전에 리퀘스트 송신 후에 리스폰스를 수신할 때까지 기다린 뒤에 리퀘스트를 요청하던 것을, 리스폰스를 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있다. 이로 인해 여러 리퀘스트를 병행해서 보내는 것이 가능하다.

Cookie

HTTP는 Stateless 프로토콜이라서 과거에 교환했었던 리퀘스트와 리스폰스의 상태를 관리하지 않는다.

쿠키는 리퀘스트와 리스폰스에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템이다. 쿠키는 서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 된다. 다음번에 클라이언트가 같은 서버로 리퀘스트를 보낼 때 자동으로 쿠키 값을 넣어서 송신한다. 서버는 클라이언트가 보낸 쿠키를 확인해서 어느 클라이언트가 접속했는지 체크하고 서버 상의 기록을 확인해서 이전 상태를 알 수 있다.

HTTP message

메시지 헤더와 메시지 바디로 구성되어 있다. 최초에 나타나는 개행 문자로 메시지 헤더와 메시지 바디를 구분한다.

HTTP Request message

리퀘스트 메시지는 메서드, URI, 프로토콜 버전, 옵션 리퀘스트 헤더 필드와 엔티티로 구성되어 있다.

HTTP Response message

리스폰스 메시지는 프로토콜 버전, 상태 코드, 상태 코드 설명, 옵션의 리스폰스 헤더 필드와 바디로 구성되어 있다.

인코딩

HTTP로 데이터를 전송할 때 그대로 전송할 수 있지만 전송할 때에 인코딩을 실시함으로써 전송 효율을 높일 수 있다. 하지만 인코딩 처리를 해야 하기 때문에 CPU 등의 리소스는 보다 많이 소비하게 된다.

• 메시지
  • HTTP 통신의 기본 단위로 옥텟 시퀀스로 구성되고 통신을 통해서 전송된다.
• 엔티티
  • 리퀘스트와 리스폰스의 페이로드로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성된다.

HTTP 메시지 바디의 역할은 리퀘스트와 리스폰스에 관한 엔티티 바디를 운반하는 일이다. 기본적으로 메시지 바디와 엔티티 바디는 같지만 전송 코딩이 적용된 경우에는 엔티티 바디의 내용이 변화하기 때문에 메시지 바디와 달라진다.

콘텐츠 코딩(Content Codings)

용량을 줄이기 위해서 파일을 zip으로 압축하고 보낼 수 있다. 콘텐츠 코딩은 엔티티에 적용하는 인코딩을 가리키는데 엔티티 정보를 유지한 채로 압축한다. 콘텐츠 코딩된 엔티티는 수신한 클라이언트 측에서 디코딩 된다.

• gzip(GNU zip)
• compress(UNIX의 표준 압축)
• deflate(zlib)
• identity(인코딩 없음)

청크 전송 코딩(Chunked transfer Coding)

엔티티 바디를 분할하는 기능을 말한다. 엔티티 바디를 청크로 분해하고 다음 청크 사이즈를 16진수를 사용해서 단락을 표시하고 엔티티 바디 끝에는 0(CR+LF)를 기록한다. 청크 전송 코딩된 바디는 수신한 클라이언트 측에서 원래의 엔티티 바디로 디코딩 한다.

Multipart

MIME(Multipurpose Internet Mail Extensions)으로 불리는 메일로 텍스트나 영상, 이미지와 같은 여러 다른 데이터를 다루기 위한 기능을 사용하고 있다. MIME는 이미지 등의 바이너리 데이터를 아스키(ASCII) 문자열에 인코딩하는 방법과 데이터 종류를 나타내는 방법 등을 규정하고 있다. 이 MIME 확장 사양에 있는 Multipart라고 하는 여러 다른 종류의 데이터를 수용하는 방법을 사용하고 있다.

HTTP도 Multipart에 대응하고 있어 하나의 메시지 바디 내부에 엔티티를 여러 개 포함시켜 보낼 수 있다. 주로 이미지나 텍스트 파일 등을 업로드할 때 사용되고 있다.

• multipart/form-data
  • Web 폼으로부터 파일 업로드에 사용된다.
• multipart/byteranges
  • 상태 코드 206(Partial Content) 리스폰스 메시지가 복수 범위의 내용을 포함할 때 사용된다.

Ragnge Request

대용량의 이미지와 데이터를 다운로드할 때 중간에 커넥션이 끊어지게 되면 처음부터 다시 다운로드해야 했다. 이러한 문제를 해결하기 위해 resume 기능이 필요하게 되었다. 이 기능으로 이전에 다운로드를 한 곳에서부터 다시 다운로드를 재개할 수 있다.

이 기능을 실현하기 위해 엔티티의 범위를 지정해서 다운로드를 할 필요가 있다. 이와 같이 범위를 지정하여 리퀘스트 하는 것을 Range Request라고 한다.

Content Negotiation

클라이언트와 서버가 제공하는 리소스의 내용에 대해 교섭하는 것을 말한다. 클라이언트에 더욱 적합한 리소스를 제공하기 위한 구조다. 메시지에 포함된 다음 리퀘스트 헤더 필드를 이용한다.

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Content-Language

Status Code

상태 코드는 클라이언트가 서버에게 리퀘스트를 보낼 때 서버에서 그 결과가 어떻게 되었는지 알려주는 역할을 한다. 예를 들면 200 OK와 같이 3자리 숫자와 설명으로 나타낸다. 숫자의 첫 번째 자리는 리스폰스의 클래스를 의미하고 나머지 2자리는 분류가 없다.

2xx 성공(Success)

2xx 리스폰스는 리퀘스트가 정상으로 처리되었음을 나타낸다.

• 204 No Content
  • 서버가 성공적으로 처리했지만 리스폰스에 엔티티 바디를 포함하지 않는다.
  • 클라이언트가 서버에 정보를 보냈고, 클라이언트에 대해서 새로운 정보를 줄 필요가 없는 경우에 사용된다.
• 206 Partial Content
  • Range Request에 의해서 서버가 부분적으로 GET 리퀘스트를 받았음을 나타낸다.
  • 리스폰스에는 지정된 범위의 엔티티가 포함되게 된다.

3xx 리다이렉트(Redirection)

3xx 리스폰스는 리퀘스트가 정상적으로 처리를 종료하기 위해 브라우저 측에서 특별한 처리를 수행해야 함을 나타낸다. 301, 302, 303 리스폰스 코드가 되돌아 오면 대부분의 브라우저에서는 POST를 GET으로 바꾸어서 리퀘스트 엔티티 바디를 삭제하고 리퀘스트를 자동적으로 재송신하도록 되어 있다.

• 301 Moved Permanently
  • 요청한 리소스에 새로운 URI가 부여되어 있어 이후로는 새로운 URI를 사용해야 함을 나타낸다.
• 302 Found
  • 요청한 리소스에는 새로운 URI가 할당되어 있기 때문에 해당 URI를 참조하라고 할 때 사용하는 코드다.
  • 301과 비슷하지만 차이점은 302는 일시적인 것이다.
• 303 See Other
  • 요청한 리소스에 대한 리소스는 다른 URI에 있다고 알리는데 사용된다.
  • 302와 비슷하지만 리다이렉트 장소를 GET 메서드로 얻어야 한다고 명확하게 되어 있는 점이 다르다.
• 304 Not Modified
  • 클라이언트가 조건부 요청을 했을 때 리소스에 대한 액세스는 허락하지만, 조건이 충족되지 않았음을 나타낸다.
  • 리스폰스 바디에 어떤 것도 포함되어 있어서는 안된다.
• 307 Temporary Redirect
  • 302 와 같은 의미를 지니지만 307에서는 브라우저 사양에 따라 POST에서 Get으로 치환을 하지 않는다.

4xx 클라이언트 에러(Client Error)

4xx는 리스폰스는 클라이언트의 원인으로 에러가 발생했음을 나타낸다.

• 400 Bad Request
  • 리퀘스트 구문이 잘못되었음을 나타낸다. 브라우저는 이것을 200 OK와 같이 취급한다.
• 401 Unauthorized
  • 송신한 리퀘스트에 HTTP 인증 정보가 필요하다는 것을 나타낸다.
• 403 Forbidden
  • 리퀘스트된 리소스의 액세스가 거부되었음을 나타내고 있다.
  • 서버에서는 거부의 이유를 분명히 할 필요가 있는데, 이유를 명확하게 하는 경우에는 엔티티 바디에 기재해서 유저 측에 표시한다.
• 404 Not Found
  • 요청한 리소스가 서버상에 없다는 것을 나타낸다.
  • 그 외에 서버 측에 해당 리퀘스트를 거부하고 싶은 이유를 분명히 하고 싶지 않은 경우에도 이용할 수 있다.

5xx 서버 에러(Server Error)

5xx 리스폰스는 서버 원인으로 에러가 발생하고 있음을 나타낸다.

• 500 Internal Server Error
  • 서버에서 리퀘스트를 처리하는 도중에 에러가 발생하였음을 나타낸다.
• 503 Service Unavailable
  • 일시적으로 서버가 과부하 상태이거나 점검 중이기 때문에 현재 리퀘스트를 처리할 수 없음을 나타낸다.
  • 이 상태가 해소되기까지 시간이 걸리는 경우에는 Retry-After 헤더 필드에 따라 클라이언트에 전달하는 것이 바람직하다.

가상 호스트(Virtual Host)

HTTP/1.1에서는 HTTP 서버에 여러 개의 웹사이트를 실행할 수 있습니다. 물리적으로는 서버가 1대지만 가상으로 여러대가 있는 것처럼 설정하는 것이 가능합니다.

Proxy

클라이언트로부터 받은 리퀘스트를 다른 서버에 전송한다. 클라이언트로부터 받은 리퀘스트 URI를 변경하지 않고 그다음의 리소스를 가지고 있는 서버에 보낸다.

리소스 본체를 가진 서버를 Origin Server라고 부른다. Origin Server로부터 되돌아온 리스폰스는 프록시 서버를 경유해서 클라이언트에게 돌아온다.

여러 대를 경유하는 것도 가능하다. 여러 대를 경유해서 중계할 때에는 Via 헤더 필드에 경유한 호스트 정보를 추가한다.

1. 캐시를 사용해서 네트워크 대역 등을 효율적으로 사용할 수 있다.
2. 조직 내에 특정 웹사이트에 대한 액세스를 제한할 수 있다.
3. 액세스 로그를 획득하는 정책을 철저하게 지키기 위해 사용한다.

캐시를 하는지와, 메시지를 변경하는지에 따라 구분할 수 있다.

캐싱 프록시

프록시로 리스폰스를 중계할 때 프록시 서버 상에 리소스 캐시를 보존하는 타입의 프록시를 말한다.

투명 프록시

프록시로 리퀘스트와 리스폰스를 중계할 때 메시지 변경을 하지 않는 타입을 말한다. 반대로 메시지에 변경을 가하는 타입의 프록시를 비투과 프록시라고 부른다.

Gateway

프록시와 동작이 매우 비슷하다. 게이트웨이의 경우는 그다음에 있는 서버가 HTTP 서버 이외의 서비스를 제공하는 서버가 된다. 클라이언트와 게이트웨이 사이를 암호화하는 등으로 안전하게 접속함으로써 통신의 안전성을 높이는 역할 등을 한다.

터널

터널은 요구에 따라서 다른 서버와의 통신 경로를 확립한다. 이 때 클라이언트는 SSL 같은 암호화 통신을 통해 서버와 안전하게 통신을 하기 위해 사용한다. 터널 자체는 HTTP 리퀘스트를 해석하지 않는다. 결국 리퀘스트를 그대로 다음 서버에 중계한다. 그리고 터널은 통신을 하고 있는 양쪽 끝에 접속이 끊어질 때에 종료한다.

Cache

캐시는 프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스의 사본을 가리킨다. 캐시를 사용하면 리소스를 가진 서버에 액세스를 줄이는 것이 가능하기 때문에 통신 시간을 절약할 수 있다.

캐시 서버는 프록시 서브의 하나로 캐싱 프록시로 분류된다. 프록시가 서버로부터 리스폰스를 중계할 때 프록시 서버 상에 리소스의 사본을 보존한다. 캐시 서버의 장점은 캐시를 이용함으로써 같은 데이터를 몇 번이고 오리진 서버에 전송할 필요가 없다는 것이다. 그래서 서버는 같은 리퀘스트를 매번 처리하지 않아도 된다.

유효기간

같은 캐시를 계속해서 사용하면 오리진 서버에 있는 원래 리소스가 갱신됐을 때 캐시 서버는 계속 이전의 리소스를 그대로 반환한다. 그래서 캐시를 가지고 있더라도 클라이언트의 요구나 캐시의 유효기간 등에 의해서 오리진 서버에 리소스의 유효성을 확인하거나 새로운 리소스를 다시 획득하러 가게 되는 경우가 있다.

클라이언트 캐시

캐시 서버만 캐시를 가지고 있는 것이 아닌 클라이언트가 사용하는 브라우저에서도 캐시를 가질 수 있다. 브라우저가 유효한 캐시를 가지고 있는 경우 같은 리소스의 액세스는 서버에 액세스하지 않고 로컬 디스크로부터 불러온다. 또한 캐시 서버와 마찬가지로 리소스가 오래된 것으로 판단된 경우에는 오리진 서버에 유효성을 확인하러 가거나 새로운 리소스를 다시 획득하러 가는 일이 있다.

HTTP 헤더 필드

헤더 필드는 HTTP 메시지를 구성하는 요소의 하나인데 부가적으로 중요한 정보를 전달하는 역할을 한다. 메시지 바디의 크기나 사용하고 있는 언어, 정보 등을 브라우저나 서버에 제공하기 위해 사용된다.

헤더 필드는 필드 명과 필드 값으로 구성되어 있고 콜론 :으로 구분한다.

헤더 필드 명 : 필드 값

예륻들면 메시지 바디의 타입을 가리킬 때 다음과 같이 작성할 수 있다.

Content-Type : text/html

또는 다음과 같이 필드명에 여러 값이 있을 수 있다.

Keep-Alive : timeout=15,max=100

헤더의 종류에는 4가지가 있다.

• 일반적 헤더 필드(General Header Fields)
  • 요청과 응답에 둘 다 사용되는 헤더
• 리퀘스트 헤더 필드(Request Header Fields)
  • 요청에 사용되는 헤더로 부가적인 정보와 클라이언트의 정보, 리스폰스 콘텐츠에 관한 우선순위 등을 부가한다.
• 리스폰스 헤더 필드(Response Header Fields)
  • 응답에 사용되는 헤더로 응답의 정보와 서버의 정보, 클라이언트의 추가 정보 요구 등을 부가한다.
• 엔티티 헤더 필드(Entity Header Fields)
  • 요청과 응답 메시지에 포함된 엔티티에 사용되는 헤더로 콘텐츠 갱신 시간 등의 엔티티에 관한 정보를 부가한다.

End-to-end 헤더와 Hop-by-end 헤더

HTTP 헤더 필드는 캐시와 비캐시 프록시의 동작을 정의하기 위해서 두 카테고리로 분류되어 있다.

• End-to-end 헤더
  • 이 카테고리 분류된 헤더는 리퀘스트나 리스폰스의 최종 수신자에게 전송된다. 캐시에서 구축된 리스폰스 중 보존돼야 하고, 다시 전송되지 않으면 안되도록 되어 있다.
• Hop-by-hop 헤더
  • 이 카테고리에 분류된 헤더는 한 번 전송에 대해서만 유효하고 캐시와 프록시에 의해서 전송되지 않는 것도 있다.
  • Connection
  • Keep-Alive
  • Proxy-Authenticate
  • Proxy-Authorization
  • Trailer
  • TE
  • Transfer-Encoding
  • Upgarde
  • 이외의 필드는 모두 End-to-end헤더에 뷴류된다.

HTTP/1.1 일반 헤더 필드

Cache-Control

Cache-Control 헤더는 디렉티블 불리는 명령을 사용하여 캐싱 동작을 지정한다. 지정한 디렉티브에는 파라미터가 있는 것과 없는 것도 있으며 여러 개의 디렉티브를 지정하는 경우에는 ,로 구분한다. 요청과 응답할 때 사용된다.

캐시 요청 디렉티브

캐시 리스폰스 디렉티브

Connection

• 프록시에 더 이상 전송하지 않는 헤더 필드를 지정
• 지속적 접속 관리

Date

HTTP 메시지를 생성한 날짜를 나타낸다.

Upgrade

HTTP 및 다른 프로토콜의 새로운 버전이 통신에 사용되는 경우에 사용된다. 지정하는 대상이 전혀 다른 통신 프로토콜이라도 상관없다.

Upgrade 헤더 필드를 사용할 때는 Connection: Upgrade도 같이 지정해야 한다.

Via

클라이언트와 서버 간의 요청 혹은 응답 메시지의 경로를 알기 위해서 사용된다. 프록시 혹은 게이트웨이는 자신의 서버 정보를 Via 헤더 필드에 추가한 뒤에 메시지를 전송한다. 전송된 메시지의 추적과 리퀘스트 루프의 회피 등에 사용된다. 따라서 프록시를 경유할 때는 반드시 이 헤더 필드에 자신의 정보를 추가해야 한다.

Warning

기본적으로 캐시에 관한 경고를 유저에게 전달한다.

Request header fields

Accept

유저 에이전트에 처리할 수 있는 미디어 타입과 미디어 타입의 상대적인 우선순위를 전달하기 위해서 사용된다. type/subtype으로 한 번에 여러 번 설정할 수 있다. 텍스트, 이미지, 동영상 그리고 애플리케이션용 바이너리 파일 등을 지정할 수 있다.

우선순위를 붙이고 싶을 경우에는 ;로 구분하고 q=로 품질 지수를 표시한다. 품질 계수는 0 ~ 1까지 소수점 3자리까지 표시하고 1이 높은 품질 계수다. 기본값은 1.0이다. 서버가 복수의 콘텐츠를 반환할 수 있는 경우에는 가장 높은 품질 계수의 미디어 타입으로 반환해야 한다.

Accept-Charset

유저 에이전트에 처리할 수 있는 문자 셋으로 상대적인 우선순위를 전달하기 위해서 사용된다.

Accept-Encoding

유저 에이전트가 처리할 수 있는 콘텐츠 코딩과 상대적인 우선순위를 전달하기 위해서 사용된다.

• gzip
• compress
• deflate
• identity

만약 *으로 와일드카드로 지정하면 모든 인코딩 포맷을 가리킨다.

Accept-Language

유저 에이전트가 처리할 수 있는 자연어의 세트와 우선순위를 전달하기 위해서 사용된다.

Authorization

유저 에이전트의 인증 정보를 전달하기 위해서 사용된다.

Host

요청한 리소스의 인터넷 호스트의 포트 번호를 전달한다. HTTP/1.1에서 필수 헤더다. 1대의 서버에서 복수의 도메인을 할당할 수 있는 가상 호스트에서는 Host 헤더 필드로 요청한 호스트명을 명확하게 구분할 수 있다.

Max-Forwards

TRACE 혹은 OPTIONS로 메소드를 호출할 때 전송해도 좋은 서버 수의 최대치를 10진수 정수로 지정한다. 요청을 받은 서버는 다음 서버에 요청을 전송할 때 1을 뺀 값으로 전송한다. 0인 요청을 받은 서버는 다음 서버로 전송하지 않고 즉시 응답을 보낸다.

프록시 서버가 여러 대의 서버를 경유해 가는 경우 도중에 프록시 서버에서 무언가의 원인으로 리퀘스트 전송이 실패하게 되면 클라이언트에서는 응답이 되돌아오지 않기 때문에 알 수 없다. 원인 조사를 하기 위해 어디까지가 정상적으로 동작하는지 확인하기 위해 사용된다.

Proxy-Authorization

프록시 서버에서의 인증 요구를 받아들일 때 인증에 필요한 클라이언트의 정보를 전달한다.

User-Agent

요청을 생성한 브라우저와 유저 에이전트의 이름 등을 전달하기 위해 사용된다.

Response header Fields

Age

얼마나 오래전에 오리진 서버에서 응답이 생성되었는지를 전달한다. 필드 값의 단위는 초다. 응답한 서버가 캐시 서버라면 캐시된 응답이 다시 실증되었던 때부터 검증한 시간이 된다. 프록시가 응답을 생성했다면 Age 헤더 필드는 필수다.

ETag

리소스를 특정하기 위한 문자열을 전달한다. 서버는 리소스마다 ETag 값을 할당한다. 리소스가 갱신되면 ETag 값도 갱신해야 한다. 값은 특별히 룰이 정해져 있지 않다. 서버에 따라서 다양한 값을 할당한다.

Location

응답의 수신자에 대해서 리소스 액세스를 유도하는 경우에 사용된다.

Proxy-Authenticate

프록시 서버에서의 인증 요구를 클라이언트에 전달한다.

Vary

캐시를 컨트롤하기 위해서 사용된다. 오리진 서버가 프록시 서버에 로컬 캐시를 사용하는 방법에 대한 지시를 전달한다. 오리진 서버로부터 Vary에 지정되었던 응답을 받아들인 프록시 서버는 이후 캐시된 때의 요청과 같은 Vary에 지정되어 있는 헤더 필드를 가진 요청에 대해서만 캐시를 반환할 수 있다. 같은 리소스에 대한 요청이라도 Vary에 지정되었던 헤더 필드가 다른 경우에는 오리진 서버로부터 리소스를 취득할 필요가 있다.

WWW-Authenticate

HTTP 액세스 인증에 사용되는데 Reqeust-URI에 지정했던 리소스에 적용할 수 있는 인증 스키마 혹은 파라미터를 나타내는 challenge를 전달한다.

WWW-Authenticate 헤더는 상태 코드 401 Unauthorized 응답에 반드시 포함된다.

쿠키를 위한 헤더 필드

Set-Cookie

서버가 클라이언트에 대해서 상태 관리를 시작했을 때 다양한 정보를 전달합니다.

Sources

• http://www.kyobobook.co.kr/product/detailViewKor.laf?barcode=9788931447897