메뉴 건너뛰기


Developer > Network
이제 드디어 Header의 각 Field에 대한 이야길 할 차례군요.
여기까지 오기 참 힘들군요. ㅠㅠ 
 
다음의 각 Header Field 뒤에 그 Field가 정의되었던 HTTP Version을 기록하였습니다. 뭐 별로 특별한 정보는 안되겠지만 참조하세요...
 
2. General Header Fields
 
General Header Field는 요청과 응답시 모두 사용될 수 있는 Header들을 정의합니다.
 
1) Date (HTTP/1.0)
 
Date는 메시지를 생성하는 시간을 기록해서 상대에게 보내는 역할을 합니다.
이를 통해 Cache와 같은 것을 유지할지 버릴지를 결정할 수 있습니다.
Date 필드에는 날짜와 시간을 적어야 하는데 이에 대한 형식도 정해져 있습니다.
사용할 수 있는 날짜와 시간 형식을 정리해 보겠는데요. 이 형식은 날짜와 시간을 적는 Header Field에는 모두 적용됩니다.
 
 
■ 날짜와 시간 형식
 
HTTP에서는 세가지 형식의 날짜와 시간을 규정하고 있습니다.
 
- RFC 822, RFC 1123 형식
ex) Sun, 06 nov 1994 08:49:30 GMT
 
- RFC 850, RFC 1036 형식
ex) Sunday, 06-Nov-94 08:49:30 GMT
 
- ANSI C의 asctime() 형식
ex) Sun Nov 6 08:49:30 1994
 
사실 세번째 ANSI C의 asctime() 형식은 사용해서는 안되는 포멧입니다. 그렇지만 다른 중계서버나 다른 Protocol과 연동을 위해 이를 해석할 수 있어야 합니다.
 
또한 모든 날짜는 GMT시간으로 표시하도록 되어 있습니다. 받아들인 시간에 GMT가 제외되어 있더라도 GMT표준시로 해석해야 합니다. Web 서버로 접속하는 웹브라우져가 웹서비스를 제공하는 나라에서만 접속되지 않는다고 생각한다면 왜 GMT로 밖에 할 수 없는지 이해하시겠죠?
 
두번째 형식은 현재 통용되고 있긴 하지만 폐기 대상입니다. 보시면 아시겠지만 년도의 표시를 2자리 수밖에 사용할 수 없어서 문제가 있죠.
 
결론적으로 여러분들이 사용할 수 있는 날짜 형식은 첫번째만 가능하다고 생각하시구요. 다른 Application과의 연동을 세가지 형식 모두 인식할 수 있어야 한다고 생각하시면 쉽습니다.
 
 
2) Pragma (HTTP/1.0)
 
Pragma는 웹브라우져와 Web Server 사이의 Proxy Server에게 전달할 "필드=값"형식의 파라메터를 정의하게 됩니다.
특수하게 "no-cache"를 사용하게 되면 Proxy Server에 Cache가 있더라도 실제 Web Server에 다시 요청한 결과를 받아 오게 하는 역할을 합니다.
그런데 HTTP/1.1에서 Cache를 제어하기 위한 좀 더 구체적인 필드인 Cache-Control가 추가되었습니다. 주의할 것은 앞으로 더 이상 Pragma의 헤더는 필요하지 않는다고 합니다. HTTP/1.1의 웹브라우져는 Pragma필드를 사용해서는 안되고 Cache-Control을 사용할 것을 권고합니다.
 
 
3) Cache-Control (HTTP/1.1)
 
Cache-Control은 캐쉬를 좀 더 효율적으로 다루기 위해 HTTP/1.0의 Pragma의 기능을 향상시키는 헤더로 추가되었습니다.
Cache-Control에 사용할 수 있는 필드값으로는 "캐쉬 요청 지시자(Cache Request Directive)"와 "캐쉬 응답 지시자(Cache Response Directive)"로 요청시와 응답시를 나눠서 사용할 수 있습니다.

캐쉬요청지시자

 no-cache[=<field-name>]
 no-store
 max-age=<delta-seconds>
 max-stale[=<delta-seconds>]
 min-fresh=<delta-seconds>
 only-if-cached

캐쉬응답지시자

 public
 private[=<field-name>]
 no-cache[=<field-name>]
 no-store
 no-transform
 must-revalidate
 proxy-revalidate
 max-age=<delta-seconds>
 
위의 표를 보니 사용할 수 있는 캐쉬지시자 꽤 많죠? 이걸 다 이해해야 하나... 저도 겁이납니다.
HTTP/1.1에서 크게 향상된 부분이 바로 비연결 지향의 문제점의 해결과 캐쉬의 효율성을 높이는 부분입니다. 그래서 캐쉬부분 관련 헤더가 좀 복잡합니다.

4) Connection (HTTP/1.1)
 
HTTP/1.0에서는 요청한후 응답을 받으면 서로의 통신을 끊는 것을 기본으로 하였습니다.
이와 같은 방식은 빈번한 접속 오버헤드가 발생하였습니다. 그래서 HTTP/1.1에서는 기본으로 요청, 응답 후 연결을 유지하는 것을 기본으로 하고 있습니다.
Connection 필드는 이와 같은 연결 유지에 대한 제어를 위한 필드입니다.
일반적으로 Connection필드의 값으로는 "close"와 "Keep Alive" 그리고 "Upgrade"를 사용합니다.
"colse"는 요청시에는 응답을 받은 후 연결을 끊겠다는 의사를 웹서버에게 알리는 역할을 합니다.
응답시에는 지금의 응답을 전송 후 연결을 끊겠다는 의사를 웹브라우져에게 알리는 역할을 합니다.
"Keep Alive"는 그 반대로 연결을 지속시킬 수 있다는 의사를 상대에게 알리는 역할을 합니다.
"Upgrade"에 대해서는 아래에 설명할 7) Upgrade 항목에서 설명하도록 하겠습니다.
 
5) Trailer (HTTP/1.1)
 
Trailer필드는 값으로 다른 헤더필드명이 올 수 있습니다. 이는 메시지 본문이 나타난 후에 다시 Trailer필드에 지정한 필드가 나타난다는 것을 의미합니다.
예를 들면 다음과 같은 응답이 올 수 있다는 것입니다.
 
HTTP/1.1 200 OK
Content-Type: text/html
Transfer-Encoding: chunked
Trailer: Date

5b
<html> <head> <title>예제</title> </head> <body> <p>전송 완료!</p> </body> </html> 0 Date: Tue, 21 May 2002 12:34:56 GMT
 
 
6) Transfer-Encoding (HTTP/1.1)
 
Transfer-Encoding필드는 메시지의 본문을 안정적으로 전송하기 위하여 전송을 어떤 방식으로 할 것인지를 지정할 수 있습니다.
HTTP/1.0에서는 Content-Length필드에 의해 전송하는 메시지의 크기를 지정하여 한번에 보내는 방식을 사용하였습니다.
Transfer-Encoding필드에 "chunked"라고 지정되면 헤더에 Content-Length를 제공하지 않고 메시지 본문을 전송할때 다음번에 전송하는 메시지의 크기를 16진수값으로 먼저 전송한 후 메시지를 전송하게 됩니다.
전송받는 입장에서 본다면 "chunked"가 지정되어 있으면 메시지 본문으로 한라인을 받아서 크기를 알고 그 크기만큼 다시 전송을 받고 다시 한라인을 전송받고를 크기가 0인 라인이 올때까지 반복하면 된다. 7)의 예제를 보면 이에 대한 내용을 볼 수 있다.
 
 
7) Upgrade (HTTP/1.1)
 
Upgrade는 사용중이 Protocol을 변경할때 사용됩니다. 예를 들어 HTTP를 사용하다가 보안을 위해서 SHTTP프로토콜을 사용하기 위해서 Upgrade 헤더를 사용할 수 있습니다.
이런 프로토콜의 변화는 강제적이지 않습니다. 왜냐하면 서버와 클라이언트가 모두 새로 사용할 프로토콜을 지원해야 하기 때문이죠. 그래서 Upgrade는 변환하겠다는 의미보다는 상대가 가능하다면 다른 프로토콜로 바꿨으면 한다라는 의미가 더 맞을 것 같습니다.
웹서버는 Upgrade 헤더 필드를 사용하기 위해 상태코드 101(Switching Protocols) 상태라인을 사용하여 클라이언트에 알려 줘야 합니다. 예를 들어 Upgrade 헤더 필드는 다음과 같이 사용할 수 있습니다.
 
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
 
위의 의미는 서버가 HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 와 같은 프로토콜을 처리할 수 있으므로 클라이언트가 이들 프로토콜 중 지원하는 프로토콜이 있으면 프로토콜을 변환하자는 의미입니다.
물론 클라이언트도 서버에게 Upgrade 헤더 필드를 보낼 수 있습니다. 하지만 지정된 프로토콜을 지원하더라도 이를 취할 것인지 취하지 않을 것인지의 결정 권한은 서버에게 있습니다.
 
 
8) Via (HTTP/1.1)
 
 
 
9) Warning (HTTP/1.1)
 
Warning 헤더 필드는 캐쉬 작업에서 의미적으로 불확실한 경우 이에 대한 경고로서 헤더에 내용을 적어 알리는 역할을  합니다.
Warning 헤더는 다음과 같이 사용할 수 있습니다.
 
Warning: <warn-code> <warn-agent> <warn-text> [<warn-date>]
 
warn-code는 경고에 대한 코드입니다. warn-agent는 전송과정에서 이 헤더를 추가한 에이전트(게이트웨이 혹은 Proxy와 같은) 의 이름을 적습니다. warn-text는 경고 메시지를 나타내며 생략가능한 warn-date는 경고가 추가된 시간을 표시할 수 있게 합니다. HTTP내에서 시간을 적을 때는 위에서 이야기한 1) Date의 입력 방식으로 입력하셔야 합니다.
 
우선 사용할 수 있는 warn-code와 경고메시지와 사용되는 때는 다음과 같습니다.
 
110 Response is stale (응답이 오래됨)
111 Revalidation faild (재검증 실패)
112 Disconnected operation (네트워크 단절)
113 Heuristic expiration (발견법상 만료)
199 Miscellaneous warning (잡다한 경고)
214 Transformation applied (전환이 적용됨)
299 Miscellaneous persistent warning (잡다한 고정된 경고)
 
warn-agent는 host[:port] 형식의 서버의 이름 혹은 별명을 적습니다.
 
 
 
Creative Commons License
Creative Commons License이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
Copyright 조희창(Nicholas Jo). Some rights reserved. http://bbs.nicklib.com