Hypertext Transfer Protocol - HTTP 1.1
하이퍼텍스트 전송 규약(HTTP)은 분산정보시스템, 종합 정보시스템 및 하이퍼미디어 정보시스템에서 사용하는 응용 계층 규약으로서 요구 방법의 확장을 통해서 네임서버와 분산 객체 관리 시스템과 같은 수많은 작업에 사용될 수 있는 보편적인 객체지향형 규약입니다. HTTP는 어떤 문서의 데이터 표현 형식을 규정하고 협상하여 전송 중인 데이터와 무관하게 시스템을 구축할 수 있게 합니다.
HTTP는 1990년 이후 World-Wide Web 범 세계 정보 이니셔티브에 의하여 사용되고 있습니다. 이 규격은 "HTTP/1.1"로 언급되는 규약을 정의하고 있습니다.
목적
하이퍼텍스트 전송 규약(HTTP)은 분산 정보시스템, 종합 정보시스템 및 하이퍼미디어 정보시스템에서 사용하는 응용계층의 규약입니다. HTTP는 1990년 이후 World-Wide Web 범 세계 정보 이니셔티브에 의하여 사용되고 있습니다. "HTTP/0.9"로 언급되는 HTTP의 첫 버전은 인터넷 상에서 저장되어 있는 원래 데이터(raw data)를 전송하기 위한 단순 규약이었습니다. RFC 1945이 규정한 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), 자원 위치(URL) 또는 자원 이름(URN)이 제공하고 참고 방법에 따라 method를 적용할 자원을 지칭하는 데 사용합니다. 메시지는 다용도 인터넷 메일 확장(MIME)에서 정의된 것처럼 인터넷 메일에서 사용되는 것과 유사한 형식으로 전송됩니다.
HTTP는 사용자 에이전트, 프록시/게이트웨이와 SMTP, NNTP, FTP, Gopher, 및 WAIS 등을 지원하는 다른 인터넷 시스템 사이의 통신을 위한 범용 규약으로서 사용됩니다. 이러한 방식으로 HTTP는 기본적인 하이퍼미디어가 다양한 애플리케이션의 자원에 접근할 수 있도록 합니다.
필요 조건
이 규격은 각각의 특별한 필요 조건의 중요도를 정의할 때 RFC 1123와 동일한 용어를 사용합니다. 이러한 용어는 다음과 같습니다.
MUST
이 단어 또는 "요구된"이라는 형용사는 해당 항목이 규격의 절대적인 필요 조건임을 의미합니다.
SHOULD
이 단어 또는 "추천된"이라는 형용사는 특정 상황에서 해당 항목을 무시할 합당한 이유가 있을 수 있다는 것을 의미합니다. 그러나 충분히 함축적 의미를 이해해야 하고 다른 방법을 선택하기 전에 사례를 충분히 검토해야 합니다.
MAY
이 단어 또는 "선택적"이라는 형용사는 해당 항목이 진정으로 선택적이라는 것을 의미합니다. 한 판매회사는 특정 항목을 특정 시장이 요구하기 때문에 또는 예를 들어 제품의 기능을 향상시켜 주기 때문에 다른 판매 회사와 달리 동일한 항목을 포함할 수 있습니다.
구현 방법이 하나 또는 그 이상의 MUST 규약 필요 조건을 충족시켜 주지 못하면 규약에 따르지 않는 것입니다. 구현 방식이 모든 MUST 및 SHOULD 필요 조건을 충족한다면 "무조건적으로 충족한다"고 할 수 있고, 모든 MUST 필요 조건을 충족하지만 모든 SHOULD 필요 조건을 충족하지 못한다면 "조건적으로 충족한다"고 할 수 있습니다.
용어
이 규격은 HTTP 통신의 참여자 및 객체가 수행하는 역할을 지칭하는 몇몇 용어를 사용하고 있습니다.
connection(연결)
통신을 목적으로 두 프로그램 간에 설정된 전송 계층의 가상적 회로
message(메시지)
HTTP 통신의 기본 전송 단위. 규정된 의미론을 따르는 구조적인 데이터 표현 형태이며, 일련의 8비트(octets)로 구성되어 있고 연결을 통하여 전송됩니다.
request(요구)
규정된 HTTP 요구 메시지.
response(응답)
규정된 HTTP 응답 메시지.
resource(자원)
규정되어 있는 URI에 의하여 식별되는 네트워크 데이터 객체 또는 서비스, 자원은 다양한 표현 형태(예를 들어 언어, 데이터 형식, 크기 및 해상도)를 지닐 수 있으며 다양한 방법으로 변형될 수 있습니다.
entity(엔터티)
요구나 응답 메시지의 페이로드(payload)로서 전송되는 정보. 엔티티는 Entity-Header 필드 형태의 메타 정보 및 Entity-Body 형태의 내용으로 구성되어 있습니다.
representation(표현)
기술한 내용 협상의 통제를 따르는 응답에 포함된 엔티티. 특정한 응답 상태와 연관된 다수의 표현 방법이 있을 수 있습니다.
content negotiation(내용 협상)
기술한 대로 요구를 처리할 때 적절한 표현 방법을 선택하는 메커니즘. 어떠한 응답에서는 엔티티의 표현은 협상할 수 있습니다.(에러 응답 포함)
variant(변형자)
자원은 특정한 경우에 자원과 관련된 하나 이상의 표현 방식을 가질 수 있습니다. 이러한 각각의 표현 방식을 "변형자"라고 부릅니다. "변형자"라는 용어를 사용한다고 해서 자원이 반드시 내용 협상의 대상인 것은 아닙니다.
client(클라이언트)
요구 메시지를 전송할 목적으로 연결을 설정하는 프로그램
user agent(사용자 에이전트)
요구 메시지를 시작하는 클라이언트. 이것은 종종 브라우저, 편집기, 편집기, 스파이더(웹을 탐색하는 로봇) 또는 다른 사용자 툴(tool)일 수 있습니다.
server(서버)
요구 메시지를 처리하기 위해 접속을 수신하는 애플리케이션으로서 응답 메시지를 전송합니다. 어떤 프로그램이든 동시에 클라이언트와 서버가 될 수 있습니다. 이 규격에서 이 용어를 사용하는 것은 프로그램의 일반적인 능력을 참조하기 보다는 특정한 연결을 위해 프로그램이 수행하는 역할만을 참조하는 것입니다. 마찬가지로 어떠한 서버도 원서버, 프록시, 게이트웨이, 터널 등 각 요구의 성격에 따라 전환하는 역할을 할 수 있습니다.
origin server(원서버)
해당 자원이 보관되어 있거나 자원을 생성할 수 있는 서버
proxy(프락시)
다른 클라이언트를 대신하여 요구를 작성할 목적으로 서버와 클라이언트의 역할을 모두 수행하는 중간 프로그램. 요구는 내부적으로 처리되어 가능하면 해석되어 다른 서버로 전달됩니다. 프록시는 이 규격의 클라이언트와 서버의 필요 조건을 모두 구현해야만 합니다.
gateway(게이트웨이)
다른 서버를 위해 중간 역할을 하는 서버. 프록시와는 달리 게이트웨이는 요구 메시지를, 요청받은 자원을 서비스하는 최종적인 원서버처럼 수신합니다. 요구한 클라이언트는 자신이 게이트웨이와 통신하고 있다는 것을 알지 못할 수 있습니다.
tunnel(터널)
두 연결 사이를 무조건 중계하는 역할을 하는 중간 프로그램. 활성화되면 비록 HTTP 요구에 의하여 시작되지만 터널은 HTTP 통신의 참여자로 간주되지 않습니다. 터널을 중계하고 있는 양 쪽의 연결이 종결되면 사라집니다.
cache(캐시)
프로그램이 응답 메시지를 저장하는 로컬 저장소, 메시지 보관, 조회 및 삭제를 제어하는 하부 시스템이기도 합니다. 캐시는 응답시간, 향후 네트워크 대역폭 소모 및 동일한 요구를 감소시킬 목적으로 캐시할 수 있는 응답을 저장합니다. 어떤 클라이언트나 서버도 캐시를 포함할 수 있습니다. 단지 터널 역할을 하는 서버는 캐시를 사용할 수 없습니다.
cachable(캐시할 수 있는)
응답 메시지의 사본을 저장하여 계속적인 요구 응답에 사용할 수 있으면 응답을 캐시할 수 있다고 합니다. HTTP 응답의 캐시 가능 여부를 결정하는 원칙도 존재합니다. 자원을 캐시할 수 있다 하더라도 캐시가 특정 요구에 대하여 캐시된 사본을 사용할 수 있는지 여부에 대한 추가적인 제한 사항이 있을 수 있습니다.
first-hand(직접)
응답이 직접적으로 오며 원서버로부터 하나 또는 그 이상의 프록시를 거쳐옴으로써 발생하는 불필요한 지연이 없을 경우 응답이 직접 온다고 할 수 있습니다. 또한 검증이 원서버에서 직접 이루어진다면 응답이 직접 온다고 할 수 있습니다.
explicit expiration time(명백한 유효 시간)
원서버가 추가적인 검증 없이는 캐시에 의해 엔티티를 더이상 되돌려 주지 않기록 한 시간. 즉, 원서버가 캐시된 데이터의 유효성을 보장할 수 있는 시간
heuristic expiration time(자동으로 설정되는 유효 시간)
분명한 유효 시간이 설정되어 있지 않을 때 캐시가 할당하는 유효 시간
age(경과 시간)
응답 메시지의 경과 시간은 원서버로부터 전송된 후, 또는 성공적으로 검증된 후의 시간
freshness lifetime(신선한 시간)
응답의 생성 시점과 유효시간 만기 시점 사이의 시간 길이
fresh(신선한)
응답의 경과 시간이 신선한 기간을 넘어서지 않았을 때 응답이 신선하다고 할 수 있습니다.
stable(낡은)
응답의 경과 시간이 신선한 기간을 넘어섰다면 응답이 낡았다고 할 수 있습니다.
semantically transparent(의미상으로 분명한)
성능을 향상시키고자 하는 목적을 제외하고 캐시의 사용이 요구하는 클라이언트나 원서버에 영향을 미치지 않을 때 특정한 요구에 대하여 캐시가 "의미상으로 분명하게" 작동한다고 할 수 있습니다. 캐시가 의미상으로 분명할 때 클라이언트는 원서버가 직접 처리했을 때와 완전히 동일할 응답을 수신하게 됩니다. (hop-by-hop 헤더는 제외)
validator(검증자)
캐시 엔트리가 엔티티의 복사본과 동일한지 알아내는 데 사용하는 규약 요소(예를 들면 엔티티 태그나 Last-Modified 시간)
Overall Operation
HTTP 규약은 요구/응답 규약입니다. 클라이언트는 요구 method, URI, 규약 버전의 형태로 서버에 요구 메시지를 전송합니다. 요구 변경자, 클라이언트 정보, 서버와의 접속에 사용되는 본문 내용을 포함하는 MIME 유형의 메시지가 뒤따릅니다. 서버는 메시지의 규약 버전 및 성공 또는 실패 코드를 포함하는 상태 정보로서 응답합니다. 서버 정보, 엔티티 메타 정보, Entity-Body 내용을 포함하는 MIME 유형의 메시지도 뒤따릅니다.
대부분의 통신은 사용자 에이전트가 구동하며 특정 원서버에 적용할 요구로 구성되어 있습니다. 가장 단순한 경우 이것은 사용자 에이전트(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가 가지고 있을 때의 결과 고리를 설명하고 있습니다.
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에서는 하나의 접속을 하나 또는 그 이상의 요구/응답 교환에 사용할 수 있으나 연결이 여러가지 이유로 단절될 수도 있습니다.
기호 관례 및 일반적인 문법
추가된 BNF
이 문서에서 명시된 모든 메커니즘은 설명형 문구로서 Backus-Naur Form(BNF)으로 설명되어 있습니다. 구현자는 이 규격을 이해하기 위하여 이러한 기호에 익숙할 필요가 있습니다. 추가된 BNF는 다음의 구성요소를 포함합니다.
name = definition
규칙의 이름이 이름 그 자체(둘러싸는 "<" 및 ">"이 없는)이며 정의 부분과는 등호 문자로 구변됩니다. 계속되는 공백 문자는 규칙에 대한 규정이 한 줄 이상에 걸쳐 있음을 표시하는 들여쓰기의 경우에만 의미가 있습니다. SP, LWS, HT, CRLF, DIGIT, ALPHA 등과 같은 몇몇 기본 규칙은 대문자로만 사용합니다. 정의문 내에서 소괄호는 규칙 이름의 사용 구별을 용이하게 해줄 경우에는 언제든지 사용합니다.
"literal"
인용 부호로 문자 텍스트 주위를 감쌉니다. 별도의 언급이 없으면 문자는 대소문자를 구별합니다.
rule1 | rule2
막대("|")로 구분된 요소는 선택사항입니다. 예를 들어 "yes|no"는 yes나 no 어느것이든 가능합니다.
(rule1 rule2)
괄호로 둘러싼 요소는 단일 요소로 취급합니다. 따라서 "(element (foo | bar) elem)"는 "elem foo elem" 및 "elem bar elem"의 토큰 순서를 허용합니다.
*rule
이것은 반복을 의미하는 것으로서 뒤이어서 나올 #rule과 혼동을 일으키는 표현 방식이므로 유의해야 합니다. 반복을 통해 이루어지는 결과는 하나의 단어나 수와 같이 한 개 요소의 표현 형태로 되는 것이며, #rule에서는 똑같은 반복이지만 여러 개 단어나 수의 열 형태와 같이 여러 개 요소의 나열 형태로 표현되는 것입니다. <n>*<m>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
특정 횟수의 반복을 나타냅니다. "<n>(element)"은 "<n>*<n>(element)"와 동일합니다. 즉 요소(element)가 정확하게 <n>번 표시됩니다. 따라서 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 표시가 가능하지만, 실제 개수는 세 개로서 간주됩니다. 따라서 최소 한 개 최대 세 개의 제한에 위배 되지 않습니다.
; comment
규칙 문장에서 오른쪽으로 약간 떨어져 있는 세미콜론은 해당 라인의 끝에까지 계속되는 주석의 시작을 의미합니다. 이것은 규격과 병행하여 적절한 설명을 포함시키기 위한 방법입니다.
implied *LWS
두 개의 인접한 단어 (token or quoted-string) 또는 인접한 토큰(tokens)과 식별자(tspecials) 사이에 LWS(linear whitespace)가 포함될 수 있습니다. 여기서 두 개의 토큰 사이에는 반드시 적어도 하나의 식별자가 존재하여 각기 하나의 토큰으로 간주되지 않게끔 구별되어야 합니다.
기본 규칙
다음의 규칙은 기본적인 분석 구조를 설명하기 위해 이 규격 전반에 걸쳐 사용되고 있습니다. US-ASCII로 코드화된 문자 집합은 ANSI X3.4-1986에 의하여 규정되었습니다.
OCTET = <모든 8BIT 연속 데이터>
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 = <US-ASCII CR, 캐리지 리턴(13)>
LF = <US-ASCII LF, 라인피드 (10)>
SP = <US-ASCII SP, 스페이스 (32)>
HT = <US-ASCII HT, 수평 탭(9)>
<''> = <US-ASCII 이중 인용 부호(34)>
HTTP/1.1은 연속적인 CR LF를 Entity-Body를 제외한 모든 규약 요소의 라인 마감 부호로 정의합니다. Entity-Body 내에서의 라인 마감부호는 연관된 media type에 의하여 정의됩니다.
CRLF = CR LF
HTTP/1.1 헤더는 계속되는 라인이 스페이스나 수평 탭으로 시작한다면 복수의 라인에 걸쳐 계속 작성할 수 있습니다. 폴딩(folding)을 포함한 모든 선형 공백 스페이스는 SP와 동일한 의미를 가집니다.
LWS = [CRLF] 1*(SP|HT)
TEXT 규칙은 메시지 분석기가 해석하지 않도록 정의한 설명 필드 내용이나 값에 사용합니다. *TEXT의 단어는 RFC 1522의 규칙에 따라 인코딩되었을 경우에만 ISO 8859-1 이외 문자세트의 문자를 포함할 수 있습니다.
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*<CTL 또는 tspecial를 제외한 모든 CHAR>
tspecials = "("|")"|"<"|">"|"@"|","|";"|":"|""|<''>|"/"|"["|"]"|"?"|"="|"{"|"}"|SP|HT
주석은 주석문을 괄호로 둘러싸서 몇몇 HTTP 헤더 필드에 포함할 수 있습니다. 주석은 "comment"를 필드 값 정의의 한 부분으로 포함하는 필드에서만 사용할 수 있습니다. 다른 필드에서 괄호는 필드 값의 일부로 간주됩니다.
comment = "(" *(ctext|comment) ")"
ctext = < "(" and ")"을 제외한 모든 TEXT >
텍스트 문자열이 이중 인용 부호를 사용하여 인용되었으면 단일 단어로 간주합니다.
quoted-string = (<''> *(qdtext) <''> )
qdtext = <<''>을 제외한 모든 TEXT)
백슬래시 문자("")는 인용된 문자열이나 주석 내에서만 단일문자 인용 메커니즘으로서 사용할 수 있습니다.
quoted-pair = "" CHAR
규약 파라미터
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 버전 값입니다.
프록시 및 게이트웨이 프로그램의 규약 버전이 애플리케이션과 상이할 경우 메시지를 전달할 때 주의해야 합니다. 규약 버전은 발송자의 규약 능력을 표시하기 때문에 프록시/게이트웨이는 실제 자신의 버전보다 높은 버전 표시를 사용하여 메시지를 발송해서는 절대로 안됩니다. 상위 버전의 요구가 수신되었다면 프록시/게이트웨이는 반드시 요구버전을 내리거나, 에러를 발송하거나 터널로 전환해야만합니다. 프록시/게이트웨이 버전보다 낮은 요구는 상위 버전으로 업그레이드 할 수는 있으나 요구 받은 버전의 주요 버전은 반드시 동일해야 합니다.
HTTP 버전 간의 변환은 관련된 버전이 요구하거나 금지한 헤더 필드의 변경을 수반할 수도 있습니다.
보편적 자원 식별자(Uniform Resource Identifier - URI)
URI는 WWW 주소, 보편적인 문서 식별자, 보편적 자원 식별자 또는 보편적 자원 위치 지정자(URL)와 이름(URN)의 결합에 이르기까지 많은 이름으로 불리우고 있습니다. HTTP로서는 보편적 자원 식별자란 이름, 위치 또는 다른 어떤 특징을 이용하여 자원을 식별해 주는 정형화 된 문자열일 뿐입니다.
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|"/")
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 및 RFC 1808을 따르고있습니다. 상기 BNF 는 RFC 1738에 명시되어 있는 유효한 URL의 형태에서 허용하지 않고 있는 국가 문자를 포함하고 있습니다. 이는 HTTP 서버가 주소에서 rel_path 부분을 표시하는 데 사용할 수 있는 예약되어 있지 않는 문자 집합에 제한을 받지않고, HTTP 프록시가 RFC 1738에 규정되지 않은 URI 요구를 수신할 수도 있기 때문입니다. HTTP 규약은 URI의 길이에 대한 어떠한 사전 제한도 두지 않습니다. 서버는 반드시 자신이 제공하는 어떠한 자원의 URI도 처리할 수 있어야 하며 이러한 URI를 생성할 수 있는 GET에 기초한 폼을 (GET-based forms) 제공한다면 무제한 길이의 URI를 처리할 수 있어야만 합니다. 서버는 URI의 길이가 자신이 처리할 수 있는 것보다 긴 경우 414 (Request-URI Too Long)을 응답으로서 돌려주어야 합니다.
서버는 255 바이트 이상의 URI 길이를 사용할 때 몇몇 이전 클라이언트나 프록시 구현 방식이 이러한 길이를 적절히 지원할 수 없는 경우가 있기 때문에 주의해야 합니다.
2. http URL
"http" scheme은 HTTP 규약을 통하여 네트워크 자원의 위치를 파악하는 데 사용합니다. 이 절은 http URL에 사용되는 scheme 특유의 형식과 의미를 규정합니다.
http_URL = "http:" "//" host [":"port] [abs_parth]
host = <합법적인 인터넷 호스트 도메인 이름 또는 RFC 1123에서 정의한 방식의 IP 주소(점으로 구분된 형식)>
port = *DIGIT
포트 항목이 비어있거나 명시되지 않았으면 포트는 80으로 간주합니다. TCP 연결 요구를 기다리고 있는 해당 호스트 서버의 해당 포트에 식별된 자원이 위치하고 있으며 자원의 Request-URI는 abs_path라는 것이 의미한다는 내용입니다. URL의 IP 주소의 사용은 가능한 한 피해야만 합니다. URL에 abs_path가 명시되어 있지 않으면 자원을 위한 Request-URI로서 사용할 때 반드시 "/"가 주어져야 합니다.
3. URI 비교
URI가 서로 일치하는지 여부를 결정하기 위해 URI를 비교할때 클라이언트는 전체 URI에 대하여 대소문자를 구별하는 8진수 대 8진수 비교방법(octet-by-octet comparison)을 사용해야만 하며 다음의 예외사항이 있습니다.
- 비어 있거나 명시되지 않은 포트는 기본 포트 80번으로 정의합니다.
- 호스트 이름의 비교에는 반드시 대소문자를 구별하지 않습니다
- scheme 이름의 비교는 반드시 대소문자를 구별하지 않습니다.
- 비어있는 abs_path는 "/"인 abs_path와 동일합니다.
"예약되거나(reserved)" "안전하지 않는(unsafe)" 문자집합 이외의 문자는 ""%" HEX HEX" 인코딩과 동일합니다.
예를 들어 다음의 세 URI는 동일합니다.
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
날짜/시간 형식
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 날짜 형식에 기초하고 있으며 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
날짜/시간 표현에 대한 HTTP 필요 조건은 규약 스트림 내부에서 사용할 때만 적용됩니다. 클라이언트와 서버는 사용자의 표시 방법, 요구 로깅 등에서는 이러한 형식을 반드시 사용해야할 필요는 없습니다.
2. Delta Seconds
몇몇 HTTP 헤더는 메시지가 수신된 이후의 시간을 10진법의 정수로 초를 명시할 수 있도록 합니다.
delta-seconds = 1*DIGIT
문자 집합
HTTP는 MIME에서 설명된 "문자 집합"이라는 용어를 동일하게 사용합니다. 일련의 8bit 데이터를 적절한 대응 관계에 있는 일련의 글자로 변환시킬 수 있도록 한 개 또는 그 이상의 표로서 만들어서 참조하게 하는 수단입니다. 그러므로 무조건 변환시켜서는 안되고, 모든 글자가 문자 집합에 정의되어 있지 않을 수 있고, 특정한 글자를 표현하기 위해 하나 이상의 8bit 데이터열이 존재할 수도 있습니다. 이 정의에 따르면 US-ASCII와 같은 단순한 변환표로부터 ISO 2022의 경우에서와 같이 복잡한 변환표에 이르기까지 다양한 종류의 문자 인코딩들을 허용합니다. 하지만 MIME 문자 집합 이름과 관련된 정의는 8bit 데이터로부터 글자로의 변환에 관한 사항을 완전하게 명시하여야 합니다. 완전한 변환 관계를 정의하기 위해 다른 수단을 통한 외부정보를 활용해서는 안됩니다.
이러한 "문자 집합"이라는 용어의 사용은 보통 "문자 인코딩"으로 지칭됩니다. 그러나 HTTP와 MIME은 동일한 등록표를 사용하기 때문에 용어를 공유하는 것 또한 중요합니다.
HTTP 문자 집합은 토큰에 의해 식별되며 대소문자를 구별하지 않습니다. 완전한 토큰 세트는 IATA 문자 집합 등록표(IANA Character Set registry)에 규정되어 있습니다.
charset = token
HTTP가 charset 값으로 임의의 토큰을 사용하도록 허용하지만 IATA 문자 집합 등록에 사전 정의된 모든 토큰은 반드시 이 등록표에 등록된 문자 집합을 표시해야 합니다. 애플리케이션은 사용하는 문자 집합을 IATA 등록 표에서 규정된 것으로 제한해야만 합니다.
내용 코딩(Content Codings)
내용 코딩 값은 엔티티에 적용하였거나 적용할 수 있는 인코딩 변환을 표시합니다. 내용 코딩은 문서를 압축하거나, 그렇지 않다면 내용의 media type의 정체를 상실하거나 정보를 손실하지 않고 유용하게 변형하는 데 사용합니다. 종종 엔터티는 코드화 된 폼에 저장되고 직접 전송되어 수신측만이 이를 해독합니다.
content-coding = token
모든 내용 코딩의 값은 대소문자를 구별하지 않습니다. HTTP/1.1은 Accept-Encoding 및 Content-Encoding 헤더 파일에 내용 코딩 값을 사용합니다. 그 값이 Content-Coding을 설명하는 것이지만 더욱 중요한 것은 인코딩을 제거하기 위해 필요한 해독 메커니즘을 표시한다는 것입니다.
인터넷에서 할당된 숫자 체계(Internet Assigned Numbers Authority (IANA))는 Content-Coding 값 토큰의 등록표 역할을 수행합니다. 처음에 이 등록표에는 다음의 토큰이 포함되어 있습니다.
* gzip
RFC 1952에 설명된 대로 파일 압축 프로그램인 "gzip"에 의하여 생성된 인코딩 포맷. 이포맷은 32 bit CRC를 가진 Lempel-Ziv coding(LZ77)입니다.
* compress
일반적은 UNIX 파일 압축 프로그램인 "compress"에 의하여 생성된 인코딩 포맷. 이 포맷은 Lempel-Ziv-Welch 코딩(LZW)을 수정한 것입니다.
인코딩 포맷을 식별하는 프로그램 이름의 사용은 바람직하지 않으며 향후 인코딩을 위해서 사용하지 말도록 권고합니다. 프로그램 이름을 여기에서 사용한 것은 역사적인 과례이며 훌륭한 디자인은 아닙니다. HTTP의 이전 구현법과 호환성을 유지하기 위해 애플리케이션은 "x-gzip" 및 "x-compress"을 "gzip"과 "compress" 각각 동일한 것으로 간주해야 합니다.
* deflate
RFC 1951에 설명된 "deflate" 압축 메커니즘과 결합하여 RFC 1950에 정의된 "zlib" 포맷.
새로운 Content-Coding 값 토큰은 등록해야 합니다. 클라이언트와 서버가 상호 운용성을 가지도록 하기 위해 새로운 값을 구현하는데 필요한 내용 코딩 알고리즘에 대한 규격은 일반인이 사용할 수 있어야하고 독립적으로 구현하기에 적합해야 하며 이 절에 규정된 내용 코딩의 목적에 따라야 합니다.
전송 코딩(Transfer Codings)
전송 코딩 값은 네트워크를 통한 "안전 전송"을 확보하기 위해 Entity-Body에 적용하였거나, 적용할 수 있거나 또는 적용할 필요가 있는 인코딩 변환을 표시하는 데 사용합니다. 전송 코딩은 메시지의 특성 중의 하나이며 원래 엔터티의 특성이 아니라는 점이 내용 코딩과 다른 점입니다.
transfer-coding = "chunked" | transfer-extension
transfer-extension = token
모든 transfer-coding 값은 대소문자를 구별하지 않습니다. HTTP/1.1은 Transfer-Encoding 헤더 필드의 전송 코딩값을 사용합니다.
전송 코딩은 7비트 전송 서비스로 바이너리 데이터를 안전하게 전송할 수 있도록 디자인 된 MIME의 Content-Transfer-Encoding 값과 유사합니다. 그러나 8비트 전송 규약에서 안전 전송의 중점은 다른 곳에 있습니다. HTTP에서 유일한 Message-Body의 불안전한 특징은 정확한 본문 길이를 결정하기 어렵다는 것과 공유하는 전송체계에서 데이터를 암호화하기 어렵다는 것입니다.
덩어리 인코딩(chunked encoding)은 메시지를 일련의 덩어리로 전송하기 위하여 메시지 본문을 변경합니다. 이 덩어리는 각각 자신의 크기 표시자를 가지고 있으며 Entity-Header 필드를 포함하고 있는 선택적인 각주(footer)가 뒤따릅니다. 이를 통하여 역동적으로 생산된 내용물이 수신인이 메시지 전체를 수신하였다는 것은 증명하는데 필요한 정보와 함께 전송될 수 있도록 합니다.
Chunked-Body = *chunk
"0" CRLF
footer
CRLF
chunk = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF
hex-no-zero = < "0"을 제외한 HEX >
chunk-size = hex-no-zero *HEX
chunk-ext = *(";" chunk-ext-name [ "=" chunk-ext-value ])
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
footer = *Entity-Header
덩어리 인코딩은 크기 0의 덩어리로 종결되며 빈 라인으로 종료되는 각주가 뒤따릅니다. 각주의 목적은 역동적으로 생성된 엔티티에 대한 정보를 효과적으로 제공하도록 하는 것입니다. 애플리케이션은 Content-MD5, 디지털 서명이나 다른 기능을 위한 HTTP 향후 확장으로 명백하게 규정되지 않은 헤더 필드를 결코 각주에 넣어서 전송해서는 안됩니다.
모든 HTTP/1.1 애플리케이션은 반드시 덩어리 전송 코딩을 해독하고 수신할 수 있어야 하며 해독할 수 없는 전송 코딩 확장은 반드시 무시해야 합니다. 해독할 수 없는 Transfer-Coding과 함께 Entity-Body를 수신하는 서버는 501(Unimplemented)을 응답으로 돌려주고 연결을 종료해야 합니다. 서버는 결코 Transfer-Coding을 HTTP/1.0 클라이언트에 보내서는 안됩니다.
미디어 형식(Media Type)
HTTP는 공개적이고 확장 가능한 데이터 유형 설정 및 유형 협상 기능을 제공하기 위해 Content-Type 및 Accept 헤더 필드의 인터넷 미디어 형식을 사용합니다.
media-type = type "/" subtype *(";" parameter)
type = token
subtype = token
attribute/value(속성/값) 쌍 형태의 파라미터가 type/subtype 유형을 뒤따릅니다.
parameter = attribute "=" value
attribute = token
value = token | quoted-string
유형, 하부 유형 및 파라미터 속성 이름은 모두 대소문자를 구분하지 않습니다. 파라미터 값은 파라미터 이름의 의미에 따라 대소문자를 구별할 수도 있고 않을 수도 있습니다. 선형 공백 스페이스(LWS)는 유형과 하부 유형, 속성과 속성 값 사이에 절대 사용해서는 안됩니다. 미디어 형식을 인지하는 사용자 에이전트는 반드시 해당 MIME 유형의 파라미터를 해당 type/subtype 정의가 설정한 방식으로 처리해야 합니다. (또는 사용자 에이전트가 해당 type/subtype을 처리하는 데 사용하는 외부 애플리케이션이 처리하도록 주선해야 합니다) 또한 발견된 모든 문제를 사용자에게 알려주어야 합니다.
이전 HTTP 애플리케이션은 미디어 형식 파라미터를 인지하지 못합니다. 이전 HTTP 애플리케이션으로 데이터를 전송할 때 구현 방식은 해당 type/subtype 정의가 요구할 때만 미디어 형식 파라미터를 사용해야 합니다.
미디어 유형 값은 인터넷 할당 숫자 체계(IANA)에 등록됩니다. 미디어 유형을 등록하는 절차는 RFC 2048에 윤곽이 설명되어 있습니다. 등록되지 않은 미디어 유형을 사용하는 것은 권하지 않습니다.
1. 정형화(Canonicalization) 및 텍스트 기본값
인터넷에서의 미디어 형식은 정형화된 형식으로서 등록되어 있습니다. 보통 HTTP 메시지를 통하여 전송되는 Entity-Body는 반드시 전송되기 이전에 적절한 정형화된 형식으로 표시되어야 합니다. 이의 예외는 다음 문구에서 정의된 "text" 유형입니다.
정형화된 형식으로서 text 형식의 미디어 subtype은 CRLF(캐리지리턴 / 라인필드), 단편적인 CR 또는 LF를 HTTP를 통하여 수신한 텍스트 미디어에서 줄 바꿈을 표시하는 것으로 인정해야만 합니다. 또한 텍스트가 몇몇 멀티바이트 문자 집합의 경우처럼 8진수 13과 10을 CR과 LF로 사용하지 않는 문자 집합을 사용하고 있을 경우 HTTP는 어떠한 일련의 octets가 해당 문자 집합에서 줄바꿈을 위한 CR 및 LF를 대표하는 것으로 규정하든 이를 허용합니다. 이러한 줄바꿈에 대한 유연성은 Entity-Body의 텍스트 미디어에만 적용되며 단편적인 CR 또는 LF는 어떠한 HTTP 제어 구조(헤더 필드 및 multipart 경계와 같은)에서도 CRLF를 대체해서는 안됩니다.
Entity-Body가 Content-Encoding으로 인코딩되었다면 내부 데이터는 인코딩되기 이전에 위에서 규정한 형식으로 표현되어 있어야 합니다.
"charset" 파라미터는 몇몇 미디어 형식에서 데이터의 문자 집합을 규정하는데 사용합니다. 송신자가 명백한 charset 파라미터를 제공하지 않았다면 "text" 유형의 미디어 subtype 형식은 HTTP를 통하여 수신했을 때 "ISO-8859-1"의 charset 기본값을 갖도록 규정되어 있습니다. "ISO-8859-1" 이외 문자 집합의 데이터나 그 하부 세트는 적절한 charset 값으로 명명되어야 합니다.
몇몇 HTTP/1.0 소프트웨어는 charset 파라미터 없는 Content-Type 헤더를 "수신측이 짐작해야한다"라고 잘못해석하였습니다. 이러한 방식을 방지하고자 하는 송신자는 charset가 ISO-8859-1 일때도 charset 파라미터를 포함할 수 있습니다. 또한 수신측에게 혼선을 주지 않는다는 것을 알 수 있을때도 그렇게 해야합니다.
불행하게도 몇몇 이전 HTTP/1.0 클라이언트는 명확한 charset 파라미터를 적절히 처리하지 못했습니다. HTTP/1.1 수신측은 송신측이 제공하는 charset 라벨을 반드시 감안해야 합니다. 또한 charset을 추측하는 조항을 가진 사용자 에이전트는 Content-Type 필드의 charset을 지원한다면 처음 문서의 내용을 표시할 때 수신측의 선호도에 따르기보다는 반드시 이 charset을 사용해야합니다.
2. Multipart Type
MIME은 많은 "multipart" 형식을 제공하고 있는데 하나 또는 그 이상의 엔티티를 단일 메시지 본문 내에 포함시킬 수 있도록 하는 것입니다. 모든 multipart 형식은 MIME에 규정되어 있는 공통적 표기법에 따르며 미디어 형식 표시값의 일부로서 경계 파라미터를 포함해야 합니다. 메시지 본문 자체는 규약의 한 요소이며, Body-Part 간의 줄 바꿈을 표시할 때 반드시 CRLF만을 사용해야 합니다. MIME과는 달리 모든 multipart 메시지의 맺음말은 반드시 비어있어야 합니다. HTTP 애플리케이션은 맺음말을 절대로 전송해서는 안됩니다. (비록 원래의 multipart가 맺음말을 포함하고 있다 하여도)
HTTP에서 multipart의 Body-Part는 해당 부분의 의미에 중대한 영향을 끼치는 헤더필드를 포함할 수 있습니다. Content-Location 헤더 필드는 URL로 확인할 수 있는 엔터티의 Body-Part에 포함되어야 합니다. 일반적으로 HTTP 사용자 에이전트는 MIME 사용자 에이전트가 multipart 유형을 수신했을때 처리하는 방식과 동일하거나 유사한 방식에 따라야 합니다.
RFC 1867에서 설명된 것처럼 "multipart/form-data" 유형이 POST 요구 method으로 처리하기에 적합한 폼 데이터를 전송하기 위해 특별히 규정되었습니다.
제품 토큰
제품 토큰은 통신 애플리케이션이 자신의 소프트웨어 이름 및 버전을 확인하는 데 사용합니다. 제품 토큰을 사용하는 대부분의 필드는 공백 문자로 구분되는 목록에 열거할 애플리케이션의 중요한 부분을 형성하는 부수적 제품명의 표시를 허용합니다. 관례상 제품은 애플리케이션을 식별해주는 제품의 중요도에 따라 열거됩니다.
product = token ["/" product-version]
product-version = token
예:
User-Agent : CERN-LineMode/2.15 libwww/2.17b3
Server : Apache/0.8.4
제품 토큰은 간략해야 하며 요점이 있어야 합니다. 광고나 필수적이지 않은 다른 정보를 위해 사용하는 것은 분명하게 금지되어 있습니다. 어떠한 토큰 문자라도 제품 정보에 표시할 수 있지만 이 토큰은 버전 식별자에만 사용해야 합니다. (동일한 제품의 계속적인 버전은 제품 값(value)의 product-version 부분만 달라야합니다.)
품질 등급 값
HTTP 내용 협상은 짤막한 "부동소수점" 숫자를 사용하여 다양한 협상 가능 파라미터의 상대적 중요성("가중치")을 표시합니다. 가중치는 최솟값 0부터 최댓값 1까지 범위의 실수로 정형화할 수 있습니다. HTTP/1.1 애플리케이션은 부동소수점 이후의 자리에 세 자리 이상의 숫자를 절대 사용해서는 안됩니다. 이러한 값들에 대한 사용자의 값 설정은 또한 다음의 방식으로 한정되어야 합니다.
qvalue = ("0"[ "." 0*3DIGIT ])
| ("1"["." 0*3("0")])
"품질등급 값"은 이 값이 단순히 원하는 품질에 대한 상대적인 질 저하를 표현하는 것이기 대문에 잘못된 명칭입니다.
언어 태그
언어 태그는 인간이 다른 인간과 정보를 교환하기 위해 말하거나, 쓰거나 혹은 전달하는 자연적인 언어를 표시합니다. 컴퓨터 언어는 분명히 제외됩니다. HTTP는 Accept-Language 및 Content-Language 필드를 이용하여 언어 태그를 표시합니다.
HTTP 언어 태그의 의미 및 등록표는 RFC 1766에서 규정한 것과 동일한 것을 사용합니다. 요약하면 언어 태그는 하나 또는 그 이상의 부분으로 구성되어 있습니다. 주요 언어 태그 및 비어 있을 수도 있는 일련의 하부 태그는 다음과 같습니다.
language-tag = primary-tag *("-" subtag)
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
태그 내에서는 공백 문자를 사용할 수 없고 모든 태그는 대소문자를 구별하지 않습니다. 언어 태그의 이름은 IANA에서 관리합니다.
태그 예제는:
en, en-US, en-cockney, i-cherokee, x-pig-latin
여기서 두 자리 문자로 되어 있는 제일 앞 태그는 ISO 639 언어 축약어 형태이며, 두 자리 문자로 되어있는 첫 하부 태그는 ISO 3166 국가코드입니다. (위에서 마지막 세 가지 태그는 등록되지 않은 태그입니다. 마지막 태그만 향후 등록될 수 있습니다)
엔터티 태그
엔터티 태그는 동일하게 요구된 자원에서 둘 또는 그 이상의 엔터티를 비교하는 데 사용합니다. HTTP/1.1은 엔터티 태그를 ETag, If-Match, If-None-Match 및 If-Range 헤더 필드에서 사용합니다. 엔터티 태그는 명쾌하지 않은 인용 문자열로 구성되어 있으며 약함(weakness) 표시자가 접두사로 붙을 수 있습니다.
entity-tag = [weak] opaque-tag
weak = "W/"
opaque-tag = quoted-string
"강한 엔터티 태그(strong entity tag)"는 8진수의 질이(octet equality) 동일할 경우에만 두 엔터티가 자원을 공유할 수 있습니다.
"W/" 접두사로 표시되는 "약한 엔터티 태그(weak entity tag)"는 엔터티가 동일하고 의미상 심각한 변화없이도 서로 대체할 수 있을 경우에만 두 엔터티가 자원을 공유할 수 있습니다. 약한 엔터티 태그는 약한 비교에만 사용할 수 있습니다.
엔터티 태그는 반드시 특정 자원과 연관된 모든 엔터티의 모든 버전을 통틀어 유일해야 합니다. 특정 엔터티 태그갑3ㅅ을 상이한 URI에 대한 요구로부터 획득한 엔터티에 동일하다는 아무런 표시없이 사용할 수 있습니다.
영역 단위
HTTP/1.1는 클라이언트가 엔터티의 일부분만 응답으로 전송해 달라고 요구할 수 있습니다. HTTP/1.1은 Range 및 Content-Range 헤더 필드의 영역 단위를 사용합니다. 엔터티는 여러 가지 구조적 단위 크기에 따라 여러 하부 영역으로 분리할 수 있습니다.
range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token
HTTP/1.1에서 정의한 유일한 영역 단위는 "바이트(bytes)"입니다. HTTP/1.1의 구현 방식은 다른 단위를 사용하여 명시한 영역을 무시할 수 있습니다. HTTP/1.1은 영역에 대한 인식 여부에 상관없이 애플리켕이션의 구현을 허용하고 있습니다.
'서버운영 (TA, ADMIN) > 네트워크' 카테고리의 다른 글
| [네트워크] 라우팅 개요 (0) | 2018.03.17 |
|---|---|
| [네트워크] RTSP(Real Time Streaming Protocol) 이란? (0) | 2018.02.28 |
| [네트워크] HTTP 헤더 구조 (1) | 2017.12.31 |
| [네트워크] 클라이언트/서버 통신 원리 (1) | 2017.11.06 |
| [네트워크] NMS와 TMN (0) | 2017.08.27 |