HTTP 1/1 전송규약

하이퍼텍스트 전송규약 1.1표준(안)

한국전자통신연구소

요약

하이퍼텍스트 전송 규약(HTTP)은 분산 정보 시스템, 종합 정보시스템 및 하이퍼미디
어 정보시스템에서 사용하는 응용 계층 규약으로서 요구 방법의 확장을 통해서 네임
서버와 분산 객체 관리 시스템과 같은 수많은 작업에 사용될 수 있는 보편적인 객체
지향형 규약이다. HTTP는 어떤 문서의 데이터 표현 형식을 규정하고 협상하여 전송
중인 데이터와 무관하게 시스템을 구축할 수 있게 한다.

HTTP는 1990년 이후 World-Wide Web 범 세계 정보 이니셔티브에 의하여 사용되고
있다. 이 규격은 "HTTP/1.1"로 언급되는 규약을 정의하고 있다.



목차

1 도입........................................................... 7
1.1 목적 ................................................... 7
1.2 필요 사항 ......................................... 7
1.3 용어 ................................................... 8
1.4 전반적인 운영 ........................... 11
2 기호 관례 및 일반적인 문법.............. 13
2.1 추가된 BNF ....................................... 13
2.2 기본적인 규칙 .................................. 15
3 규약 파라미터............................... 17
3.1 HTTP 버전 ........................................ 17
3.2 보편적 자원 식별자(Uniform Resource Identifiers) ........................ 18
3.2.1 일반적 형식 ............................. 18
3.2.2 http URL ......................................... 19
3.2.3 URI 비교 .................................. 20
3.3 날짜/시간 형식................................... 21
3.3.1 완전한 날짜 ................................. 21
3.3.2 Delta Seconds ................. 22
3.4 문자 집합 .......................................... 22
3.5 내용 코딩 (Content Coding)............. 23
3.6 전송 코딩 (Transfer Coding)............ 24
3.7 미디어 타입 ...................................... 25
3.7.1 정형화(Canonicalization) 및 텍스트 기본값 ............... 26
3.7.2 Multipart Type .................................... 27
3.8 제품 토큰 ...................................... 28
3.9 품질 등급 값.................................. 28
3.10 언어 태그...................................... 28
3.11 엔터티 태그....................................... 29
3.12 영역 단위 ..................................... 30
4 HTTP 메시지......................................... 30
4.1 메시지 유형 ................................... 30
4.2 메시지 헤더 ................................... 31
4.3 메시지 본문 ................................... 32
4.4 메시지 길이 ................................... 32
4.5 일반적인 헤더 필드 ..................... 34
5 요구........................................................ 34
5.1 Request-Line ........................................ 34
5.1.1 Method ......................................... 35
5.1.2 Request-URI ...................................... 35
5.2 요구에 의해 식별되는 자원 ......... 37
5.3 요구 헤더 필드 ............................... 37
6 응답.......................................................... 38
6.1 상태-라인 .......................................... 38
6.1.1 상태 코드 및 이유 문구 .......... 39
6.2 응답 헤더 필드 ............................... 41


[Page 1]


7 엔터티(Entity).......................................................... 41
7.1 엔터티 헤더 필드 ................................ 41
7.2 엔터티 본문 ......................................... 42
7.2.1 유형 .............................................. 42
7.2.2 길이 ............................................………………………………………………………... 43
8 접속.......................................................... 43
8.1 지속적인 접속 ................................. 43
8.1.1 목적 .............................................. 43
8.1.2 전반적인 운영.............................. 44
8.1.3 프락시 서버(Proxy Servers) ........ 45
8.1.4 실제적인 고려 사항 .................. 45
8.2 메시지 전송 필요 조건 ................. 46
9 Method 정의............................. 48
9.1 안전 및 멱등원(冪等元) method .. 48
9.1.1 안전 method..................................... 48
9.1.2 멱등원 method................................. 49
9.2 OPTIONS ............................................... 49
9.3 GET ........................................................ 50
9.4 HEAD .................................................... 50
9.5 POST ...................................................... 51
9.6 PUT ........................................................ 52
9.7 DELETE ................................................. 53
9.8 TRACE ................................................... 53
10 상태 코드 정의....................................... 53
10.1 Informational 1xx (정보를 알려 주는 1xx) .................................. 54
10.1.1 100 Continue (계속)..................................................................... 54
10.1.2 101 Switching Protocols (규약 전환).................................. 54
10.2 Successful 2xx (성공을 알려 주는 2xx) ....................................................... 54
10.2.1 200 OK ......................................................................................... 54
10.2.2 201 Created (생성 되었음) ......................................................... 55
10.2.3 202 Accepted (접수 되었음)....................................................... 55
10.2.4 203 Non-Authoritative Information (비 인증 정보) .................. 55
10.2.5 204 No Content (내용이 없음) ......................... ...... ...... ........... 55
10.2.6 205 Reset Content (내용을 지움)............................ ...... ............ 56
10.2.7 206 Partial Content (부분적 내용)....................... ...... ............... 56
10.3 Redirection 3xx (방향을 재설정하는 3xx)..................................... 56
10.3.1 300 Multiple Choices (복수 선택).......................... ...... .... ........ 57
10.3.2 301 Moved Permanently (영구 이동).............. ........................... 57
10.3.3 302 Moved Temporarily (임시 이동).......................................... 58
10.3.4 303 See Other (다른 것을 참조)................................................. 58
10.3.5 304 Not Modified (변경되지 않았음)......................................... 58
10.3.6 305 Use Proxy (프락시를 사용할 것)........................................ 59
10.4 Client Error 4xx (클라이언트 에러 4xx)......................................... 59
10.4.1 400 Bad Request (잘못된 요구)................................................... 60
10.4.2 401 Unauthorized (인증되지 않았음).......................................... 60
10.4.3 402 Payment Required (요금 지불 요청).................................... 60
10.4.4 403 Forbidden (금지되었음)........................................………………………….............. 60


[Page 2]



10.4.5 404 Not Found (찾을 수 없음)..................................................... 60
10.4.6 405 Method Not Allowed (Method를 사용할 수 없음).............. 61
10.4.7 406 Not Acceptable (접수할 수 없음)......................................... 61
10.4.8 407 Proxy Authentication Required (프락시 인증이 필요함).... 61
10.4.9 408 Request Timeout (요구 시간 초과)....................................... 62
10.4.10 409 Conflict (충돌)....................................................................... 62
10.4.11 410 Gone (내용물이 사라졌음).................................................. 62
10.4.12 411 Length Required (길이가 필요함)........................................ 63
10.4.13 412 Precondition Failed (사전 조건 충족 실패)........................ 63
10.4.14 413 Request Entity Too Large (요구 엔터티가 너무 큼)............. 63
10.4.15 414 Request-URI Too Long (Request-URI이 너무 김).................. 63
10.4.16 415 Unsupported Media Type (지원되지 않는 media type).. 63
10.5 Server Error 5xx (서버 에러 5xx)...................................................... 64
10.5.1 500 Internal Server Error (서버 내부 에러).................................. 64
10.5.2 501 Not Implemented (구현되지 않았음)..................................... 64
10.5.3 502 Bad Gateway (불량 게이트웨이) .................................................... 64
10.5.4 503 Service Unavailable (서비스를 사용할 수 없음) ......................... 64
10.5.5 504 Gateway Timeout (게이트웨이 시간 초과).................................... 64
10.5.6 505 HTTP Version Not Supported (지원되지 않는 HTTP 버전) ........ 65
11 접속 인증 .................................................................... 65
11.1 기본 인증 scheme ........................................ 66
11.2 요약 인증 scheme ....................................................... 67
12 내용 협상(Content Negotiation).................................... 67
12.1 서버가 주도하는 협상 ......................................... 68
12.2 에이전트가 주도하는 협상................................... 69
12.3 투명한 협상(Transparent Negotiation ) .................. 70
13 HTTP에서의 캐시........................................................ 70
13.1.1 캐시의 정확성 .................................................. 72
13.1.2 경고 .................................................................... 73
13.1.3 캐시-제어 메커니즘 ......................................... 74
13.1.4 명백한 사용자 에이전트 경고 ...................... 74
13.1.5 규칙 및 경고의 예외 사항 ............................ 75
13.1.6 클라이언트가 제어하는 행태 ........................ 75
13.2 유효일 모델 ........................................................... 75
13.2.1 서버가 명시한 만기일 .................................... 75
13.2.2 스스로 만기일을 찾음(Heuristic Expiration) .. 76
13.2.3 경과 시간 계산(Age Calculations) ................... 77
13.2.4 만기일 계산 ...................................................... 79
13.2.5 만기일 값을 명확하게 하기 ......................... 80
13.2.6 복수의 응답을 명확하게 하기 ...................... 80
13.3 검증 모델 ............................................................... 81
13.3.1 최종 갱신 날짜 ................................................ 82
13.3.2 엔터티 태그 캐시 검증자(Validators) ................ 82
13.3.3 약한/강한 검증자 ............................................. 82
13.3.4 엔터티 태그와 최종 갱신 날짜를 사용할 때를 결정하는 규칙....... 85
13.3.5 검증을 하지 않는 조건 법 ................................................................. 86
13.4 응답을 캐시할 수 있는 정도(Cachability) .....................……………................…..….... 86


[Page 3]



13.5 캐시에서 응답을 구축하기 .......................... 87
13.5.1 End-to-end 및 Hop-by-hop 헤더 ............... 88
13.5.2 변경할 수 없는 헤더 ............................... 88
13.5.3 헤더의 결합 ............................................... 89
13.5.4 바이트 영역(Byte Ranges)의 결합............ 90
13.6 협상을 통한 응답을 캐시하기 .................... 90
13.7 공유/비공유 캐시............................................. 91
13.8 에러 또는 불완전한 응답 캐시 행태 ....... 91
13.9 GET 및 HEAD의 부작용 ............................. 92
13.10 갱신 또는 삭제 후의 무효화 .................... 92
13.11 의무적으로 서버를 통하여 기입................ 93
13.12 캐시 대체 ...................................................... 93
13.13 History List ................................ 93
14 헤더 필드 정의..................................................... 94
14.1 Accept ..................................................... 95
14.2 Accept-Charset............................. 97
14.3 Accept-Encoding................................ 97
14.4 Accept-Language.................................... 98
14.5 Accept-Ranges ...................................... 99
14.6 Age........................................................... 99
14.7 Allow........................................... 100
14.8 Authorization......................................... 100
14.9 Cache-Control.................................... 101
14.9.1 무엇을 캐시할 수 있는가................................ 103
14.9.2 캐시에 의해 무엇을 저장할 수 있는가........ 103
14.9.3 기본적인 만기일 메커니즘의 변경 .............. 104
14.9.4 캐시의 재검증 및 Reload 제어 ................... 105
14.9.5 비 변경 지시어 ................................................ 107
14.9.6 캐시 제어 확장.................................................. 108
14.10 Connection............................................... 109
14.11 Content-Base................................ 109
14.12 Content-Encoding.................... 110
14.13 Content-Language........................ 110
14.14 Content-Length.............................. 111
14.15 Content-Location......................... 112
14.16 Content-MD5.............................. 113
14.17 Content-Range....................... 114
14.18 Content-Type.......................... 116
14.19 Date................................................ 116
14.20 ETag ......................................................................... 117
14.21 Expires....................................................... 117
14.22 From....................................................... 118
14.23 Host..................................................... 119
14.24 If-Modified-Since .................................................... 119
14.25 If-Match ................................................................... 121
14.26 If-None-Match ......................................................... 122
14.27 If-Range ................................................................... 123
14.28 If-Unmodified-Since ................................................ 124
14.29 Last-Modified ..................……………………………………………………………........... 124


[Page 4]



14.30 Location........................................... 125
14.31 Max-Forwards............................. 125
14.32 Pragma ...................................................................... 126
14.33 Proxy-Authenticate................. 127
14.34 Proxy-Authorization................ 127
14.35 Public ........................................................................ 127
14.36 Range........................................................ 128
14.36.1 Byte Ranges................ 128
14.36.2 Range Retrieval Requests 130
14.37 Referer............................................ 131
14.38 Retry-After.............................. 131
14.39 Server....................................................... 132
14.40 Transfer-Encoding.............. 132
14.41 Upgrade....................................... 132
14.42 User-Agent........................ 134
14.43 Vary......................................................... 134
14.44 Via......................................................... 135
14.45 Warning............................................... 137
14.46 WWW-Authenticate...................... 139
15 보안에 대한 고려 사항............................................... 139
15.1 클라이언트의 인증 ............................................... 139
15.2 인증 scheme을 선택할 수 있도록 함 ................................... 140
15.3 서버 로그 정보의 남용 ....................................... 141
15.4 민감한 정보의 전송 ............................................. 141
15.5 파일 및 경로 이름에 기초한 공격 ................... 142
15.6 개인적인 정보 ........................................................... 143
15.7 Accept 헤더와 연결된 사생활 보호의 이슈 ........... 143
15.8 DNS Spoofing(속이기) ............................................ 144
15.9 Location 헤더와 Spoofing(속이기) ........................ 144
16 감사의 말...................................................................... 144
17 참고 문헌...................................................................... 146
18 저자의 주소.................................................................. 149
19 부록................................................................................ 150
19.1 Internet Media Type message/http...................... 150
19.2 Internet Media Type multipart/byteranges ............ 150
19.3 Tolerant Applications............................. 151
19.4 HTTP 엔터티와 MIME 엔터티의 차이점......................................................... 152
19.4.1 규범적인 폼으로 변환 .................................... 152
19.4.2 날짜 형식의 변환 ............................................ 153
19.4.3 Content-Encoding 소개............................................... 153
19.4.4 No Content-Transfer-Encoding ........................................ 153
19.4.5 Multipart Body-Part의 HTTP 헤더 필드 ....... 153
19.4.6 Transmit-Encoding 소개 ............................................. 154
19.4.7 MIME-Version ..................................................………………………………………...... 154



[Page 5]



19.5 HTTP/1.0 이후 변경 사항 .................................... 154
19.5.1 복수의 홈을 가진 웹 서버를 단순하게 하기 위한 변경 사항 및
IP 주소 보존 ..................................................... 155
19.6 추가 기능 ............................................................... 156
19.6.1 추가적인 요구 method ............................................ 156
19.6.2 추가 헤더 필드 정의 ...................................... 156
19.7 이전 버전과의 호환성 ......................................... 160
19.7.1 HTTP/1.0 지속적인 연결과의 호환성............. 161















[Page 6]


1 서론

1.1 목적

하이퍼텍스트 전송 규약(HTTP)은 분산 정보시스템, 종합 정보시스템 및 하이퍼미디어 정보시
스템에서 사용하는 응용계층의 규약이다. HTTP는 1990년 이후 World-Wide Web 범 세계 정보
이니셔티브에 의하여 사용되고 있다. "HTTP/0.9"로 언급되는 HTTP의 첫 버전은 인터넷 상에
서 저장되어 있는 원래 데이터(raw data)를 전송하기 위한 단순한 규약이었다. RFC 1945 [6]이
규정한 HTTP/1.0은 메시지를 전송되는 문서 데이터에 대한 메타 정보 및 요구/응답 용어의
변경자를 포함하는 MIME과 유사한 메시지의 형식으로 사용할 수 있도록 함으로써 규약을 향
상시켰다. 그러나 HTTP/1.0은 계층적 프락시(hierarchical proxies), 캐시, 지속적인 연결의 필요
성 및 가상 호스트(virtual host) 등의 영향을 충분히 고려하지 않았다. 또한 "HTTP/1.0"을 지원
한다고 하면서도 규약의 불완전 구현 및 오해에 의한 잘못된 구현 등에 의해 응용 프로그램
사이에 종종 문제가 발생하였기에 상호 협상할 수 있는 응용 프로그램이 상대방의 진정한 성
능을 파악할 수 있도록 규약 버전을 갱신할 필요가 생겼다.

이 규격은 "HTTP/1.1"로 불리우는 하이퍼텍스트 전송 규약을 정의한다. 이 규약은 기능을 신
뢰할 수 있도록 구현하기 위해 HTTP/1.0보다 더 엄격한 필요 조건을 포함하고 있다.

실제적인 정보 시스템은 단순한 조회보다 검색, 프런트-엔드(front-end) 갱신 및 주석 달기 등
많은 기능을 필요로 한다. HTTP는 요구의 목적을 표시하는 일련의 개방된 method를 (open-
ended set of methods) 허용한다. 이 규약은 보편적 자원 식별자(URI) [3][20], 자원 위치 (URL) [4]
또는 자원 이름(URN)이 제공하는 참고 방법에 따라 method를 적용할 자원을 지칭하는 데 사
용한다. 메시지는 다용도 인터넷 메일 확장(MIME)에서 정의된 것처럼 인터넷 메일에서 사용
되는 것과 유사한 형식으로 전송된다.

HTTP는 사용자 에이전트, 프락시/게이트웨이와 SMTP [16], NNTP [13], FTP [18], Gopher [2], 및
WAIS [10] 등을 지원하는 다른 인터넷 시스템 사이의 통신을 위한 범용 규약으로서 사용된다.
이러한 방식으로 HTTP는 기본적인 하이퍼미디어가 다양한 애플리케이션의 자원에 접근할 수
있도록 한다.

1.2 필요 조건

이 규격은 각각의 특별한 필요 조건의 중요도를 정의할 때 RFC 1123 [8]와 동일한 용어를 사
용한다. 이러한 용어는 다음과 같다.

MUST
이 단어 또는 "요구된"이라는 형용사는 해당 항목이 규격의 절대적인 필요 조건임을 의미
한다.

[Page 7]


SHOULD
이 단어 또는 "추천된"이라는 형용사는 특정 상황에서 해당 항목을 무시할 합당한 이유가
있을 수 있다는 것을 의미한다. 그러나 충분히 함축적 의미를 이해해야 하고 다른 방법을
선택하기 전에 사례를 충분히 검토해야 한다.

MAY
이 단어 또는 "선택적"이라는 형용사는 해당 항목이 진정으로 선택적이라는 것을 의미한
다. 한 판매회사는 특정 항목을 특정 시장이 요구하기 때문에 또는 예를 들어 제품의 기능
을 향상시켜 주기 때문에 다른 판매 회사와 달리 동일한 항목을 포함할 수 있다.

구현 방법이 하나 또는 그 이상의 MUST 규약 필요 조건을 충족시켜 주지 못하면 규약에 따
르지 않는 것이다. 구현 방식이 모든 MUST 및 SHOULD 필요 조건을 충족한다면 "무조건적으
로 충족한다"고 할 수 있고, 모든 MUST 필요 조건을 충족하지만 모든 SHOULD 필요 조건을
충족하지 못한다면 "조건적으로 충족한다"고 할 수 있다.

1.3 용어

이 규격은 HTTP 통신의 참여자 및 객체가 수행하는 역할을 지칭하는 몇몇 용어를 사용하고
있다.

connection(연결)
통신을 목적으로 두 프로그램 간에 설정된 전송 계층의 가상적 회로

message(메시지)
HTTP 통신의 기본 전송 단위. 4 장에 규정된 의미론을 따르는 구조적인 데이터 표현 형태
이며, 일련의 8 비트(octets)로 구성되어 있고 연결을 통하여 전송된다.

request(요구)
5 장에 규정된 HTTP 요구 메시지.

response(응답)
5 장에 규정된 HTTP 응답 메시지.

resource(자원)
3.2절에 규정되어 있는 URI에 의하여 식별되는 네트워크 데이터 객체 또는 서비스. 자원
은 다양한 표현 형태 (예를 들어 언어, 데이터 형식, 크기 및 해상도)를 지닐 수 있으며 다
양한 방법으로 변형될 수 있다.

[Page 8]


entity(엔터티)
요구나 응답 메시지의 페이로드(payload)로서 전송되는 정보. 엔터티는 7 장에서 설명된 대
로 Entity-Header 필드 형태의 메타 정보 및 Entity-Body 형태의 내용으로 구성되어 있다.

representation(표현)
12 장에서 기술한 내용 협상의 통제를 따르는 응답에 포함된 엔터티. 특정한 응답 상태와
연관된 다수의 표현 방법이 있을 수 있다.

content negotiation(내용 협상)
12 장에서 기술한 대로 요구를 처리할 때 적절한 표현 방법을 선택하는 메커니즘. 어떠한
응답에서는 엔터티의 표현은 협상할 수 있다.(에러 응답 포함)

variant(변형자)
자원은 특정한 경우에 자원과 관련된 하나 이상의 표현 방식을 가질 수 있다. 이러한 각각
의 표현 방식을 "변형자"라고 부른다. "변형자"라는 용어를 사용한다고 해서 자원이 반드
시 내용 협상의 대상인 것은 아니다.

client(클라이언트)
요구 메시지를 전송할 목적으로 연결을 설정하는 프로그램.

user agent(사용자 에이전트)
요구 메시지를 시작하는 클라이언트. 이것은 종종 브라우저, 편집기, 스파이더(웹을 탐색하
는 로봇) 또는 다른 사용자 툴(tool)일 수 있다.

server(서버)
요구 메시지를 처리하기 위해 접속을 수신하는 애플리케이션으로서 응답 메시지를 전송한
다. 어떤 프로그램이든 동시에 클라이언트와 서버가 될 수 있다. 이 규격에서 이 용어를
사용하는 것은 프로그램의 일반적인 능력을 참조하기보다는 특정한 연결을 위해 프로그램
이 수행하는 역할만을 참조하는 것이다. 마찬가지로 어떠한 서버도 원서버, 프락시, 게이트
웨이, 터널 등 각 요구의 성격에 따라 동작을 전환하는 역할을 할 수 있다.

origin server(원서버)
해당 자원이 보관되어 있거나 자원을 생성할 수 있는 서버.

[Page 9]


proxy(프락시)
다른 클라이언트를 대신하여 요구를 작성할 목적으로 서버와 클라이언트의 역할을 모두
수행하는 중간 프로그램. 요구는 내부적으로 처리되어 가능하면 해석되어 다른 서버로 전
달된다. 프락시는 이 규격의 클라이언트와 서버의 필요 조건을 모두 구현해야만 한다.

gateway(게이트웨이)
다른 서버를 위해 중간 역할을 하는 서버. 프락시와는 달리 게이트웨이는 요구 메시지를,
요청받은 자원을 서비스하는 최종적인 원서버처럼 수신한다. 요구한 클라이언트는 자신이
게이트웨이와 통신하고 있다는 것을 알지 못할 수 있다.

tunnel(터널)
두 연결 사이를 무조건 중계하는 역할을 하는 중간 프로그램. 활성화되면 비록 HTTP 요구
에 의하여 시작되지만 터널은 HTTP 통신의 참여자로 간주되지 않는다. 터널은 중계하고
있는 양 쪽의 연결이 종결되면 사라진다.

cache(캐시)
프로그램이 응답 메시지를 저장하는 로컬 저장소. 메시지 보관, 조회 및 삭제를 제어하는
하부 시스템이기도 하다. 캐시는 응답 시간, 향후 네트워크 대역폭 소모 및 동일한 요구를
감소시킬 목적으로 캐시할 수 있는 응답을 저장한다. 어떤 클라이언트나 서버도 캐시를 포
함할 수 있다. 단지 터널 역할을 하는 서버는 캐시를 사용할 수 없다.

cachable(캐시할 수 있는)
응답 메시지의 사본을 저장하여 계속적인 요구 응답에 사용할 수 있으면 응답을 캐시할
수 있다고 한다. HTTP 응답의 캐시 가능 여부를 결정하는 원칙은 13 장에 정의되어 있다.
자원을 캐시할 수 있다 하더라도 캐시가 특정 요구에 대하여 캐시 된 사본을 사용할 수
있는지 여부에 대한 추가적인 제한 사항이 있을 수 있다.

first-hand(직접)
응답이 직접적으로 오며 원서버로부터 하나 또는 그 이상의 프락시를 거쳐옴으로써 발생
하는 불필요한 지연이 없을 경우 응답이 직접 온다고 할 수 있다. 또한 검증이 원서버에서
직접 이루어진다면 응답이 직접 온다고 할 수 있다.

explicit expiration time(명백한 유효 시간)
원서버가 추가적인 검증 없이는 캐시에 의해 엔터티를 더 이상 되돌려 주지 않기로 한 시
간. 즉, 원서버가 캐시된 데이터의 유효성을 보장할 수 있는 시간.

[Page 10]


heuristic expiration time(자동으로 설정되는 유효 시간)
분명한 유효 시간이 설정되어 있지 않을 때 캐시가 할당하는 유효 시간

age(경과 시간)
응답 메시지의 경과 시간은 원서버로부터 전송된 후, 또는 성공적으로 검증된 후의 시간.

freshness lifetime(신선한 기간)
응답의 생성 시점과 유효시간 만기 시점 사이의 시간 길이

fresh(신선한)
응답의 경과 시간이 신선한 기간을 넘어서지 않았을 때 응답이 신선하다고 할 수 있다.

stale(낡은)
응답의 경과 시간이 신선한 기간을 넘어섰다면 응답이 낡았다고 할 수 있다.

semantically transparent(의미상으로 분명한)
성능을 향상시키고자 하는 목적을 제외하고 캐시의 사용이 요구하는 클라이언트나 원서버
에 영향을 미치지 않을 때 특정한 요구에 대하여 캐시가 "의미상으로 분명하게" 작동한다
고 할 수 있다. 캐시가 의미상으로 분명할 때 클라이언트는 원서버가 직접 처리했을 때와
완전히 동일할 응답을 수신하게 된다.( hop-by-hop 헤더는 제외).

validator(검증자)
캐시 엔트리가 엔터티의 복사본과 동일한지 알아내는 데 사용하는 규약 요소(예를 들면
엔터티 태그나 Last-Modified 시간)

1.4 Overall Operation

HTTP 규약은 요구/응답 규약이다. 클라이언트는 요구 method, URI, 규약 버전의 형태로 서
버에 요구 메시지를 전송한다. 요구 변경자, 클라이언트 정보, 서버와의 접속에 사용되는
본문 내용을 포함하는 MIME 유형의 메시지가 뒤따른다. 서버는 메시지의 규약 버전 및
성공 또는 실패 코드를 포함하는 상태 정보로서 응답한다. 서버 정보, 엔터티 메타 정보,
Entity-Body 내용을 포함하는 MIME 유형의 메시지도 뒤따른다.

[Page 11]



대부분의 통신은 사용자 에이전트가 구동하며 특정 원서버에 적용할 요구로 구성되어 있다.
가장 단순한 경우 이것은 사용자 에이전트(UA)와 원서버(O) 사이의 단일 접속(v)에 의해 성취
할 수 있을 것이다.

request chain ---------------------->
UA ---------------- v ------------------- O
<--------------------- response chain

좀 더 복잡한 상황은 Request/Response chain에 하나 또는 그 이상의 중간 매개자가 있는 경우
이다. 프락시, 게이트웨이 및 터널의 세 가지 일반적인 중간 매개 형태가 있다. 프락시는 전송
에이전트로 절대 표현 형태의 URI 요구를 수신하여 메시지의 전체 혹은 부분을 재작성한 후
URI가 표시하는 서버로 재구성된 요구 메시지를 전달한다. 게이트웨이는 수신 에이전트로 다
른 서버 위의 계층 역할을 수행하며 필요하다면 원서버의 규약에 맞도록 요구를 해석하기도
한다. 터널은 메시지를 변경하지 않고 두 연결 지점을 연결하는 중계역할을 수행한다. 터널은
통신(communication)이 중간 매개자가 메시지의 내용을 이해할 수 없을 때라도 방화벽과 같은
중간 매개자를 통과할 필요가 있을 때 사용한다.

request chain ------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------ response chain

위의 도표는 사용자 에이전트와 원서버 사이의 세 중간 매개자(A, B 및 C)를 보여 준다. 전체
고리를 통과하는 요구 또는 응답 메시지는 네 개의 별도 연결을 통과하게 된다. 몇몇 HTTP
통신 선택 사항은 최고 근접 거리의 비터널 이웃과의 통신, 연쇄적 연결 고리의 마지막 부분
에만 또는 연결 고리에 따르는 모든 연결에 적용되기 때문에 이러한 구분은 중요하다. 그림이
선형이지만 각 참여자는 복수의 동시 통신에 참여할 수 있다. 예를 들어 B는 A의 요구를 처
리함과 동시에 A를 제외한 복수의 클라이언트 요구를 수신하고/수신하거나 C 이외의 서버에
게 요구를 전송할 수 있다.

터널 역할을 수행하는 것이 아닌 통신에 참여하는 어떤 것이라도 요구를 처리할 때 내부 캐시
를 사용할 수 있다. 캐시의 효과는 연결 고리를 따라 참가자 중 하나가 해당되는 요구에 적용
할 수 있는 캐시된 응답을 갖고 있다면 Request/Response chain이 짧아진다. 다음은 UA 또는 A
가 캐시하지 않은 요구에 대한 O (C를 경유) 초기 응답의 사본을 B가 가지고 있을 때의 결과
고리를 설명하고 있다.

[Page 12]


request chain --------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<-------- response chain

보통 모든 응답을 캐시할 수 있는 것은 아니며 어떤 요구는 캐시 방식에 특별 요구를 하는 변
경자를 포함할 수 있다. 13 장에 캐시 방식과 캐시할 수 있는 응답에 대한 필요 조건이 기록되
어 있다.

사실상 World Wide Web에는 현재 실험되고 있거나 배포되고 있는 캐시와 프락시의 다양한 아
키텍쳐와 환경설정 방법이 있다. 이러한 것 중에는 대륙간 대역폭을 절약하기 위한 프락시 캐
시의 국가적 계층, 캐시 엔트리를 배포하거나 복수로 배포하는 시스템, CD-ROM 등을 통하여
캐시 된 데이터의 하부 세트를 배포하는 조직 등이 있다. HTTP 시스템은 광대역 연결을 통한
기업 인트라넷, 저동력 무선 연결의 PDA를 통한 연결 및 간헐적인 연결에 사용된다. HTTP/1.1
의 목적은 고도의 신뢰성과 신뢰성을 확보할 수 없다면 신뢰할 수 있는 실패의 표시 기능을
지닌 웹 응용프로그램을 개발하는 개발자의 요구를 충족하는 규약 구조물을 새로 소개하면서
도 이미 배포된 다양한 환경을 지원하는 것이다.

HTTP 통신은 대개 TCP/IP 연결을 통하여 이루어진다. 기본 포트는 TCP 80 이지만 다른 포트
를 사용할 수도 있다. 그러나 이것은 HTTP가 인터넷 상의 다른 규약이나 다른 네트워크 위에
서 구현될 수 없게 하는 것은 아니다. HTTP는 단순히 신뢰할 수 있는 전송 수단을 가정할 뿐
이며 이러한 보장을 해 줄 수 있는 어떠한 규약을 사용해도 된다. HTTP/1.1의 요구 응답 구조
를 적용하고자 하는 규약의 전송 데이터 단위로 배치(mapping)하는 것은 이 규격의 범위 밖의
것이다.

HTTP/1.0에서 대부분의 구현 방식은 각각의 요구/응답 교환에 새로운 접속을 사용하는 것이
다. 또한 HTTP/1.1에서는 하나의 접속을 하나 또는 그 이상의 요구/응답 교환에 사용할 수 있
으나 연결이 여러 가지 이유로 단절될 수 있다.( 8.1 절 참조)

2 기호 관례 및 일반적인 문법

2.1 추가된 BNF

이 문서에서 명시된 모든 메커니즘은 설명형 문구로서 RFC 822 [9]에서 사용한 것과 유사한
추가된 Backus-Naur Form (BNF)으로 설명되어 있다. 구현자는 이 규격을 이해하기 위하여 이러
한 기호에 익숙할 필요가 있다. 추가된 BNF는 다음의 구성 요소를 포함한다.

[Page 13]


name = definition
규칙의 이름이 이름 그 자체(둘러싸는 "<" 및 ">"이 없는)이며 정의 부분과는 등호 문자("=")
로 구별된다. 계속되는 공백 문자는 규칙에 대한 규정이 한 줄 이상에 걸쳐 있음을 표시하
는 들여쓰기의 경우에만 의미가 있다. SP, LWS, HT, CRLF, DIGIT, ALPHA 등과 같은 몇몇 기본
규칙은 대문자로만 사용한다. 정의문 내에서 소괄호는 규칙 이름의 사용 구별을 용이하게
해줄 경우에는 언제든지 사용한다.

"literal"
인용 부호로 문자 텍스트 주위를 감싼다. 별도의 언급이 없으면 문자는 대소문자를 구별한
다.

rule1 | rule2
막대 ("|")로 구분된 요소는 선택 사항이다. 예를 들어 "yes |no" 는 yes 나 no어느 것이든 가
능하다.

(rule1 rule2)
괄호로 둘러싼 요소는 단일 요소로 취급한다. 따라서 "(elem (foo | bar) elem)"는
"elem foo elem" 및 "elem bar elem"의 토큰 순서를 허용한다.

*rule
이것은 반복을 의미하는 것으로서 뒤이어서 나올 #rule과 혼동을 일으키는 표현 방식이므
로 유의해야 한다. 반복을 통해 이루어지는 결과는 하나의 단어나 수와 같이 한 개 요소의
표현 형태로 되는 것이며, #rule에서는 똑같은 반복이지만 여러 개 단어나 수의 열 형태
와 같이 여러 개 요소의 나열 형태로 표현되는 것이다. *element와 같은 표기 방
법으로 쓰인다. 이것은 적어도 n개와 최대 m개의 요소로 구성되는 한 가지 결과를 의미한
다. 즉, 1*2DIGIT 라는 표현은 숫자가 적어도 한 개 최대 두 개로 구성되어 한 개의 수를
나타낸다는 뜻이다. 4는 한 가지 예이며, 45도 한 가지 예가 된다. 그러나 345의 경우
에는 숫자 세 개로 구성된 한 개 요소이므로 최대 갯수에 위배되어 적합하지 않다.
n과 m은 생략될 수 있으며, 이 경우에 n의 기본값은 0이고 m의 기본값은 무한대이다.
그러므로 "*(element)"는 0개를 포함해서 어떤 개수라도 가능하고, "1*element"의 경
우는 한 요소의 표현에 있어 적어도 한 개는 있어야 하며 최대 갯수에는 제한이 없다.

[rule]
대괄호는 선택 요소를 둘러 싼다. "[foo bar]" 는 "*1(foo bar)"와 동일하다.

N rule
특정 횟수의 반복을 나타낸다. "(element)" 은 "*(element)"와 동일하다.
즉 요소(element)가 정확하게 번 표시된다. 따라서 2 DIGIT 는 2 자리 숫자, 3 ALPHA
는 세 개의 알파벳 문자로 구성된 문자열이다.

#rule
앞서 설명한 것처럼 반복을 나타내긴 하지만 요소들의 나열로서 표현되는 것이다. 즉,
1#DIGIT 라고 하면 여러 개의 수로 구성된 수열로서 표현되는데, 최소 한 개의 수는 있어
야 하고 최대 갯수는 제한이 없는 수열이 된다. 각 요소들 사이의 구분은 ","와 LWS를 이
용하는데, 여러 개의 나열 형태를 쉽게 표현할 수 있게 해준다. 예를 들어, (*LWS
element *(*LWS "," *LWS element)) 이것을 간단하게 1#element 이와 같이 표현할
수 있다. 또 다른 예를 들자면, 1#2(2DIGIT)이것은 숫자 두 개로 구성된 수가 적어도 한
개가 있어야 하며 최대 두 개까지 가능하다는 것이다. 즉, 23 이렇게 표현될 수도 있고,
23, 56 이렇게 두 개로 표현될 수도 있다. 이것이 *rule과의 차이점이고, #rule 에서도
"#element" 의 구성이 그대로 성립한다. 이에 대한 설명은 *rule 의 경우와 같다. ","
를 이용하여 나열함에 있어, null element가 허용된다. 예를 들어, 1#3(2DIGIT)과 같
은 표현식에 대해23, , 56, 34 이렇게 null element 표시가 가능하지만, 실제 갯수는
세 개로서 간주된다. 따라서 최소 한 개 최대 세 개의 제한에 위배되지 않는다.

[Page 14]



; comment
규칙 문장에서 오른쪽으로 약간 떨어져 있는 세미콜론은 해당 라인의 끝에까지 계속되는 주
석의 시작을 의미한다. 이것은 규격과 병행하여 적절한 설명을 포함시키기 위한 방법이다.

implied *LWS
두 개의 인접한 단어 (token or quoted-string) 또는 인접한 토큰(tokens)과 식별자
(tspecials) 사이에 LWS (linear whitespace)가 포함될 수 있다. 여기서 두 개의 토큰 사이에
는 반드시 적어도 하나의 식별자가 존재하여 각기 하나의 토큰으로 간주되지 않게끔 구별되
어야 한다.

2.2 기본 규칙

다음의 규칙은 기본적인 분석 구조를 설명하기 위해 이 규격 전반에 걸쳐 사용되고 있다. US-
ASCII로 코드화 된 문자 집합은 ANSI X3.4-1986 [21]에 의하여 규정되었다.

OCTET = <모든 8-bit 연속 데이터>
CHAR = <모든 US-ASCII 문자 (octets 0 - 127)>
UPALPHA = <모든US-ASCII 대문자 "A".."Z">
LOALPHA = <모든 US-ASCII 소문자 "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <모든 US-ASCII 숫자 "0".."9">
CTL = <모든 US-ASCII 제어 문자 (octets 0 - 31) 및 DEL (127)>
CR =
LF =
SP =
HT =
<"> =

[Page 15]



HTTP/1.1은 연속적인 CR LF를 Entity-Body를 (부록 19.3 참조) 제외한 모든 규약 요소의
라인 마감 부호로 정의한다. Entity-Body 내에서의 라인 마감 부호는 3.7 절에서 설명된 것
처럼 연관된 media type에 의하여 정의한다.

CRLF = CR LF

HTTP/1.1 헤더는 계속되는 라인이 스페이스나 수평 탭으로 시작한다면 복수의 라인에 걸쳐 계
속 작성할 수 있다. 폴딩(folding)을 포함한 모든 선형 공백 스페이스는 SP와 동일한 의미를
가진다.

LWS = [CRLF] 1*( SP | HT )

TEXT 규칙은 메시지 분석기가 해석하지 않도록 정의한 설명 필드 내용이나 값에 사용한다.
*TEXT의 단어는 RFC 1522 [14]의 규칙에 따라 인코딩되었을 경우에만 ISO 8859-1 [22] 이외 문
자세트의 문자를 포함할 수 있다.

TEXT = < CTLs을 제외한 (그러나 LWS는 포함) 모든 OCTET>

16 진수 숫자는 몇몇 규약 요소에서 사용할 수 있다.

HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

많은 HTTP/1.1 헤더 필드 값은 LWS나 특수 문자로 구별되는 단어로 구성되어 있다. 파라미
터 값 내에서 사용할 이러한 특별 문자는 반드시 인용 문자열 내에 있어야 한다.

token = 1*

tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | ""
| <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT

주석은 주석문을 괄호로 둘러싸서 몇몇 HTTP 헤더 필드에 포함할 수 있다. 주석은
"comment"를 필드 값 정의의 한 부분으로 포함하는 필드에서만 사용할 수 있다. 다른 필드
에서 괄호는 필드 값의 일부로 간주된다.

comment = "(" *( ctext | comment ) ")"
ctext = < "(" and ")"을 제외한 모든 TEXT >

[Page 16]



텍스트 문자열이 이중 인용 부호를 사용하여 인용되었으면 단일 단어로 간주한다.

quoted-string = ( <"> *(qdtext) <"> )

qdtext = <<">을 제외한 모든 TEXT>

백슬래시 문자("")는 인용된 문자열이나 주석 내에서만 단일문자 인용 메커니즘으로서 사용할
수 있다.

quoted-pair = "" CHAR

3 규약 파라미터

3.1 HTTP 버전

HTTP는 "<주요한 변경>.<사소한 변경>" 번호 체계를 규약의 버전을 표시할 때 사용한다. 규
약 버전 부여 정책은 발송자가 통신을 통하여 획득한 기능보다는 메시지의 형식 및 계속적인
HTTP 통신을 이해할 능력이 있음을 표시할 수 있도록 하기 위해 정의되었다. 단순히 확장할
수 있는 필드 값을 추가하거나 통신 방식에 영향을 미치지 않는 메시지 구성 요소를 추가했을
경우에는 버전 숫자에 변화가 없다. <사소한 변경> 숫자는 일반적인 메시지 분석 알고리즘에
대한 변화는 없지만 메시지 의미에 대한 추가 사항이나 발송자의 추가적인 능력을 의미하는
규약 추가 기능에 대한 변경이 있을 경우 증가된다. <주요한 변경> 숫자는 규약 내부의 메시
지 형식이 변경되었을 때 증가한다.

HTTP 메시지의 버전은 메시지 첫 라인의 HTTP-Version 필드에 표시된다.

HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT

주요 및 사소한 부분을 표시하는 숫자는 반드시 별도의 정수 값으로 구분되어야 하며 10 단위
이상으로 증가할 수 있음을 주의해야 한다. 따라서 HTTP/2.4 은 HTTP/2.13보다 이전 버전이
며 또한 HTTP/12.3보다 이전 버전이다. 수신측에서는 앞 부분에 나오는 0을 반드시 무시해야
하며 전송해서는 안 된다.

이 규격이 규정하는 대로 요구나 응답 메시지를 전송하는 애플리케이션은 반드시 HTTP-
Version을 "HTTP/1.1"로 설정해야 한다. 이 버전 번호를 사용하는 것은 발송하는 애플리케
이션이 최소한 부분적으로는 이 규격을 따르고 있음을 표시한다.

애플리케이션의 HTTP 버전은 해당 프로그램이 최소한의 조건으로 상호 동작을 지원할 수 있
는 최고 HTTP 버전 값이다.

[Page 17]


프락시 및 게이트웨이 프로그램의 규약 버전이 애플리케이션과 상이할 경우 메시지를 전달할
때 주의해야 한다. 규약 버전은 발송자의 규약 능력을 표시하기 때문에 프락시/게이트웨이는
실제 자신의 버전보다 높은 버전 표시를 사용하여 메시지를 발송해서는 절대로 안 된다. 상위
버전의 요구가 수신되었으면 프락시/게이트웨이는 반드시 요구 버전을 내리거나, 에러를 발송
하거나 터널로 전환해야만 한다. 프락시/게이트웨이 버전보다 낮은 요구는 상위 버전으로 업그
레이드 할 수는 있으나 요구 받은 버전의 주요 버전은 반드시 동일해야 한다.

주의: HTTP 버전 간의 변환은 관련된 버전이 요구하거나 금지한 헤더 필드의 변경을 수반할
수도 있다.

3.2 보편적 자원 식별자(Uniform Resource Identifier - URI)

URI는 WWW 주소, 보편적인 문서 식별자, 보편적 자원 식별자 또는 보편적 자원 위치 지정
자(URL)와 이름(URN)의 결합에 이르기까지 많은 이름으로 불리우고 있다. HTTP로서는 보편
적 자원 식별자란 이름, 위치 또는 다른 어떤 특징을 이용하여 자원을 식별해 주는 정형화 된
문자열일 뿐이다.

3.2.1 일반적 형식

HTTP 규약에서 URI는 사용되는 상황에 따라 절대적인 형태로 표현할 수도 있고 알려진 기본
URI의 상대적인 형태로 표현할 수도 있다. 이 두 형태는 절대적 URI는 항상 콜론이 뒤 따르
는 scheme으로 시작한다는 사실로 구분할 수 있다.

URI = ( absoluteURI | relativeURI ) [ "#" fragment ]

AbsoluteURI = scheme ":" *( uchar | reserved )

RelativeURI = net_path | abs_path | rel_path

net_path = "//" net_loc [ abs_path ]
abs_path = "/" rel_path
rel_path = [ path ] [ ";" params ] [ "?" query ]

path = fsegment *( "/" segment )
fsegment = 1*pchar
segment = *pchar

params = param *( ";" param )
param = *( pchar | "/" )

[Page 18]


scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc = *( pchar | ";" | "?" )

query = *( uchar | reserved )
fragment = *( uchar | reserved )

pchar = uchar | ":" | "@" | "&" | "=" | "+"
uchar = unreserved | escape
unreserved = ALPHA | DIGIT | safe | extra | national

escape = "%" HEX HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
safe = "$" | "-" | "_" | "."
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
national = < ALPHA, DIGIT, reserved, extra, safe
및unsafe을 제외한 모든 OCTET>

URL 형식과 의미 규정에 관한 정보는 RFC 1738 [4] 및 RFC 1808 [11]을 따르고 있다. 상기
BNF 는 RFC 1738에 명시되어 있는 유효한 URL의 형태에서 허용하지 않고 있는 국가 문자
를 포함하고 있다. 이는 HTTP 서버가 주소에서 rel_path 부분을 표시하는 데 사용할 수 있
는 예약되어 있지 않는 문자 집합에 제한을 받지 않고, HTTP 프락시가 RFC 1738에 규정되지
않은 URI 요구를 수신할 수도 있기 때문이다.

HTTP 규약은 URI의 길이에 대한 어떠한 사전 제한도 두지 않는다. 서버는 반드시 자신이 제
공하는 어떠한 자원의 URI도 처리할 수 있어야 하며 이러한 URI를 생성할 수 있는 GET에
기초한 폼을 (GET-based forms) 제공한다면 무제한 길이의 URI를 처리할 수 있어야만 한다. 서
버는 URI의 길이가 자신의 처리할 수 있는 (10.4.15 절 참조) 것보다 긴 경우 414 (Request-URI
Too Long)를 응답으로서 돌려주어야 한다.

주의: 서버는 255 바이트 이상의 URI 길이를 사용할 때 몇몇 이전 클라이언트나 프락시 구
현 방식이 이러한 길이를 적절히 지원할 수 없는 경우가 있기 때문에 주의해야 한다.

3.2.2 http URL

"http" scheme은 HTTP 규약을 통하여 네트워크 자원의 위치를 파악하는 데 사용한다. 이 절은
http URL에 사용되는 scheme 특유의 형식과 의미를 규정한다.

[Page 19]


http_URL = "http:" "//" host [ ":" port ] [ abs_path ]

host = <합법적인 인터넷 호스트 도매인 이름 또는 RFC 1123의 2.1 절에서 정
의한 방식의 IP 주소(점으로 구분된 형식)>

port = *DIGIT

포트 항목이 비어 있거나 명시되지 않았으면 포트는 80으로 간주한다. TCP 연결 요구를 기다
리고 있는 해당 호스트 서버의 해당 포트에 식별된 자원이 위치하고 있으며 자원의
Request-URI는 abs_path라는 것이 의미한다는 내용이다. URL의 IP 주소의 사용은 가능한
한 피해야만 한다 (RFC 1900 [24] 참조). URL에 abs_path가 명시되어 있지 않으면 자원(5.1.2
절)을 위한 Request-URI로서 사용할 때 반드시 "/"가 주어져야 한다.

3.2.3 URI 비교

URI가 서로 일치하는지 여부를 결정하기 위해 URI를 비교할 때 클라이언트는 전체URI에
대하여 대소문자를 구별하는 8진수 대 8진수 비교 방법(octet-by-octet comparison)을 사용해야
만 하며 다음의 예외 사항이 있다.

? 비어 있거나 명시되지 않은 포트는 기본 포트 80번으로 정의한다;

? 호스트 이름의 비교에는 반드시 대소문자를 구별하지 않는다;

? scheme 이름의 비교는 반드시 대소문자를 구별하지 않는다;

? 비어 있는 abs_path는 "/"인 abs_path와 동일하다.

"예약되거나(reserved)" "안전하지 않는(unsafe)" 문자 집합 (3.2 절 참조) 이외의 문자는 ""%"
HEX HEX" 인코딩과 동일하다.

예를 들어 다음의 세 URI는 동일하다.

http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html

[Page 20]


3.3 날짜/시간 형식

3.3.1 완전한 날짜

HTTP 프로그램은 역사적으로 세 가지 방법으로 시간/날짜를 표시해 왔다.

Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, RFC 1123에서 갱신
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, RFC 1036에서 폐기
Sun Nov 6 08:49:37 1994 ; ANSI C의 asctime() 형식

첫번째의 형식이 인터넷 표준으로 우선권을 가지고 있으며 RFC 1123 (RFC 822의 개정판)에서
규정한 고정 길이의 하부 세트를 표시한다. 두 번째 형식은 일반적으로 사용되기는 하지만 폐
기된 RFC 850 [12] 날짜 형식에 기초하고 있으며 4 단위 년도 표시가 결여되어 있다. 날짜를
분석하는 HTTP/1.1 클라이언트 및 서버는 반드시 상기 세 형식을 모두 수용해야 한다. 그러나
헤더 필드의 HTTP-날짜 값을 표시할 때는 반드시 RFC 1123 형식만을 생산해야 한다.

주의 : 날짜 값 수신처는 메시지를 프락시/게이트웨이를 통하여 SMTP나 NNTP로 조회 또
는 발송하는 경우처럼 비 HTTP 애플리케이션이 발송한 날짜 값을 수신하는 데 적극적인 조
치를 취할 것을 장려한다.

모든 HTTP 날짜/시간 표시는 예외 없이 반드시 그린이치 표준 시간(GMT))을 따라야 한다. 이
는 처음 두 형식에서 시간대를 표시하는 3 문자의 축약어인 "GMT"를 포함함으로써 표시되어
있다. 또한 asctime 형식의 날짜를 읽을 때도 "GMT"라고 반드시 가정해야 한다.

HTTP-date = rfc1123-date | rfc850-date | asctime-date

rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT

date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59

wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun"

[Page 21]


weekday = "Monday" | "Tuesday" | "Wednesday" | "Thursday"
| "Friday" | "Saturday" | "Sunday"

month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun"
| "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"

주의: 날짜/시간 표현에 대한 HTTP 필요 조건은 규약 스트림 내부에서 사용할 때만 적용된
다. 클라이언트와 서버는 사용자의 표시 방법, 요구 로깅 등에서는 이러한 형식을 반드시 사
용해야 할 필요는 없다.

3.3.2 Delta Seconds

몇몇 HTTP 헤더는 메시지가 수신된 이후의 시간을 10진법의 정수로 초를 명시할 수 있도록
한다.

delta-seconds = 1*DIGIT

3.4 문자 집합

HTTP는 MIME에서 설명된 "문자 집합"이라는 용어를 동일하게 사용한다.

일련의 8bit 데이터를 적절한 대응 관계에 있는 일련의 글자로 변환시킬 수 있도록 한 개 또
는 그 이상의 표로서 만들어서 참조하게 하는 수단이다. 그러므로 무조건 변환시켜서는 안
되고, 모든 글자가 문자 집합에 정의되어 있지 않을 수 있고, 특정한 글자를 표현하기 위해
하나 이상의 8bit 데이터열이 존재할 수도 있다. 이 정의에 따르면, US-ASCII와 같은 단순한
변환표로부터 ISO 2022의 경우에서와 같이 복잡한 변환표에 이르기까지 다양한 종류의 문자
인코딩들을 허용한다. 하지만 MIME 문자 집합 이름과 관련된 정의는 8bit 데이터로부터 글
자로의 변환에 관한 사항을 완전하게 명시하여야 한다. 완전한 변환 관계를 정의하기 위해
다른 수단을 통한 외부 정보를 활용해서는 안 된다.

주의 : 이러한 "문자 집합"이라는 용어의 사용은 보통 "문자 인코딩"으로 지칭된다. 그러나
HTTP와 MIME은 동일한 등록표를 사용하기 때문에 용어를 공유하는 것 또한 중요하다.

[Page 22]


HTTP 문자 집합은 토큰에 의해 식별되며 대소문자를 구별하지 않는다. 완전한 토큰 세트는
IATA 문자 집합 등록표(IANA Character Set registry [19])에 규정되어 있다.

charset = token

HTTP가 charset 값으로 임의의 토큰을 사용하도록 허용하지만 IATA 문자 집합 등록에 사전
정의된 모든 토큰은 반드시 이 등록표에 등록된 문자 집합을 표시해야 한다. 애플리케이션은
사용하는 문자 집합을 IATA 등록 표에서 규정된 것으로 제한해야만 한다.

3.5 내용 코딩(Content Codings)

내용 코딩 값은 엔터티에 적용하였거나 적용할 수 있는 인코딩 변환을 표시한다. 내용 코딩은
문서를 압축하거나, 그렇지 않다면 내용의 media type의 정체를 상실하거나 정보를 손실하지
않고 유용하게 변형하는 데 사용한다. 종종 엔터티는 코드화 된 폼에 저장되고 직접 전송되어
수신측만이 이를 해독한다.

content-coding = token

모든 내용 코딩의 값은 대소문자를 구별하지 않는다. HTTP/1.1은 Accept-Encoding (14.3 절)
및 Content-Encoding (14.12 절) 헤더 파일에 내용 코딩 값을 사용한다. 그 값이 Content-
Coding을 설명하는 것이지만 더욱 중요한 것은 인코딩을 제거하기 위해 필요한 해독 메커니
즘을 표시한다는 것이다.

인터넷에서 할당된 숫자 체계(Internet Assigned Numbers Authority (IANA))는 Content-Coding
값 토큰의 등록표 역할을 수행한다. 처음에 이 등록표에는 다음의 토큰이 포함되어 있다.

gzip
RFC 1952 [25]에 설명된 대로 파일 압축 프로그램인 "gzip"에 의하여 생성된 인코딩 포
맷. 이 포맷은 32 bit CRC를 가진 Lempel-Ziv coding (LZ77)이다.

'IT > HTTP' 카테고리의 다른 글

HTTP Status Code 정리  (0)	2005.02.25