출처 : 한국전자통신연구소요약하이퍼텍스트 전송 규약(HTTP)은 분산 정보 시스템, 종합 정보시스템 및 하이퍼미디어 정보시스템에서사용하는 응용 계층 규약으로서 요구 방법의 확장을 통해서 네임 서버와 분산 객체 관리 시스템과 같은수많은 작업에 사용될 수 있는 보편적인 객체 지향형 규약이다. HTTP는 어떤 문서의 데이터 표현 형식을규정하고 협상하여 전송 중인 데이터와 무관하게 시스템을 구축할 수 있게 한다.HTTP는 1990년 이후 World-Wide Web 범 세계 정보 이니셔티브에 의하여 사용되고 있다.이 규격은 "HTTP/1.1"로 언급되는 규약을 정의하고 있다.
목차 1. 도입 1.1 목적 1.2 필요 사항 1.3 용어 1.4 전반적인 운영 2. 기호 관례 및 일반적인 문법 2.1 추가된 BNF 2.2 기본적인 규칙 3. 규약 파라미터 3.1 HTTP 버전 3.2 보편적 자원 식별자(Uniform Resource Identifiers) 3.2.1 일반적 형식 3.2.2 http URL 3.2.3 URI 비교 3.3 날짜/시간 형식 3.3.1 완전한 날짜 3.3.2 Delta Seconds 3.4 문자 집합 3.5 내용 코딩 (Content Coding) 3.6 전송 코딩 (Transfer Coding) 3.7 미디어 타입 3.7.1 정형화(Canonicalization) 및 텍스트 기본값 3.7.2 Multipart Type 3.8 제품 토큰 3.9 품질 등급 값 3.10 언어 태그 3.11 엔터티 태그 3.12 영역 단위 4. HTTP 메시지 4.1 메시지 유형 4.2 메시지 헤더 4.3 메시지 본문 4.4 메시지 길이 4.5 일반적인 헤더 필드 5. 요구 5.1 Request-Line 5.1.1 Method 5.1.2 Request-URI 5.2 요구에 의해 식별되는 자원 5.3 요구 헤더 필드 6. 응답 6.1 상태-라인 6.1.1 상태 코드 및 이유 문구 6.2 응답 헤더 필드 7 엔터티(Entity) 7.1 엔터티 헤더 필드 7.2 엔터티 본문 7.2.1 유형 7.2.2 길이 8. 접속 8.1 지속적인 접속 8.1.1 목적 8.1.2 전반적인 운영 8.1.3 프락시 서버(Proxy Servers) 8.1.4 실제적인 고려 사항 8.2 메시지 전송 필요 조건 9. Method 정의 9.1 안전 및 멱등원(冪等元) method 9.1.1 안전 method 9.1.2 멱등원 method 9.2 OPTIONS 9.3 GET 9.4 HEAD 9.5 POST 9.6 PUT 9.7 DELETE 9.8 TRACE 10. 상태 코드 정의 10.1 Informational 1xx (정보를 알려 주는 1xx) 10.1.1 100 Continue (계속) 10.1.2 101 Switching Protocols (규약 전환) 10.2 Successful 2xx (성공을 알려 주는 2xx) 10.2.1 200 OK 10.2.2 201 Created (생성 되었음) 10.2.3 202 Accepted (접수 되었음) 10.2.4 203 Non-Authoritative Information (비 인증 정보) 10.2.5 204 No Content (내용이 없음) 10.2.6 205 Reset Content (내용을 지움) 10.2.7 206 Partial Content (부분적 내용) 10.3 Redirection 3xx (방향을 재설정하는 3xx) 10.3.1 300 Multiple Choices (복수 선택) 10.3.2 301 Moved Permanently (영구 이동) 10.3.3 302 Moved Temporarily (임시 이동) 10.3.4 303 See Other (다른 것을 참조) 10.3.5 304 Not Modified (변경되지 않았음) 10.3.6 305 Use Proxy (프락시를 사용할 것) 10.4 Client Error 4xx (클라이언트 에러 4xx) 10.4.1 400 Bad Request (잘못된 요구) 10.4.2 401 Unauthorized (인증되지 않았음) 10.4.3 402 Payment Required (요금 지불 요청) 10.4.4 403 Forbidden (금지되었음) 10.4.5 404 Not Found (찾을 수 없음) 10.4.6 405 Method Not Allowed (Method를 사용할 수 없음) 10.4.7 406 Not Acceptable (접수할 수 없음) 10.4.8 407 Proxy Authentication Required (프락시 인증이 필요함) 10.4.9 408 Request Timeout (요구 시간 초과) 10.4.10 409 Conflict (충돌) 10.4.11 410 Gone (내용물이 사라졌음) 10.4.12 411 Length Required (길이가 필요함) 10.4.13 412 Precondition Failed (사전 조건 충족 실패) 10.4.14 413 Request Entity Too Large (요구 엔터티가 너무 큼) 10.4.15 414 Request-URI Too Long (Request-URI이 너무 김) 10.4.16 415 Unsupported Media Type (지원되지 않는 media type) 10.5 Server Error 5xx (서버 에러 5xx) 10.5.1 500 Internal Server Error (서버 내부 에러) 10.5.2 501 Not Implemented (구현되지 않았음) 10.5.3 502 Bad Gateway (불량 게이트웨이) 10.5.4 503 Service Unavailable (서비스를 사용할 수 없음) 10.5.5 504 Gateway Timeout (게이트웨이 시간 초과) 10.5.6 505 HTTP Version Not Supported (지원되지 않는 HTTP 버전) 11. 접속 인증 11.1 기본 인증 scheme 11.2 요약 인증 scheme 12. 내용 협상(Content Negotiation) 12.1 서버가 주도하는 협상 12.2 에이전트가 주도하는 협상 12.3 투명한 협상(Transparent Negotiation ) 13. HTTP에서의 캐시 13.1.1 캐시의 정확성 13.1.2 경고 13.1.3 캐시-제어 메커니즘 13.1.4 명백한 사용자 에이전트 경고 13.1.5 규칙 및 경고의 예외 사항 13.1.6 클라이언트가 제어하는 행태 13.2 유효일 모델 13.2.1 서버가 명시한 만기일 13.2.2 스스로 만기일을 찾음(Heuristic Expiration) 13.2.3 경과 시간 계산(Age Calculations) 13.2.4 만기일 계산 13.2.5 만기일 값을 명확하게 하기 13.2.6 복수의 응답을 명확하게 하기 13.3 검증 모델 13.3.1 최종 갱신 날짜 13.3.2 엔터티 태그 캐시 검증자(Validators) 13.3.3 약한/강한 검증자 13.3.4 엔터티 태그와 최종 갱신 날짜를 사용할 때를 결정하는 규칙 13.3.5 검증을 하지 않는 조건 법 13.4 응답을 캐시할 수 있는 정도(Cachability) 13.5 캐시에서 응답을 구축하기 13.5.1 End-to-end 및 Hop-by-hop 헤더 13.5.2 변경할 수 없는 헤더 13.5.3 헤더의 결합 13.5.4 바이트 영역(Byte Ranges)의 결합 13.6 협상을 통한 응답을 캐시하기 13.7 공유/비공유 캐시 13.8 에러 또는 불완전한 응답 캐시 행태 13.9 GET 및 HEAD의 부작용 13.10 갱신 또는 삭제 후의 무효화 13.11 의무적으로 서버를 통하여 기입 13.12 캐시 대체 13.13 History List 14. 헤더 필드 정의 14.1 Accept 14.2 Accept-Charset 14.3 Accept-Encoding 14.4 Accept-Language 14.5 Accept-Ranges 14.6 Age 14.7 Allow 14.8 Authorization 14.9 Cache-Control 14.9.1 무엇을 캐시할 수 있는가 14.9.2 캐시에 의해 무엇을 저장할 수 있는가 14.9.3 기본적인 만기일 메커니즘의 변경 14.9.4 캐시의 재검증 및 Reload 제어 14.9.5 비 변경 지시어 14.9.6 캐시 제어 확장 14.10 Connection 14.11 Content-Base 14.12 Content-Encoding 14.13 Content-Language 14.14 Content-Length 14.15 Content-Location 14.16 Content-MD5 14.17 Content-Range 14.18 Content-Type 14.19 Date 14.20 ETag 14.21 Expires 14.22 From 14.23 Host 14.24 If-Modified-Since 14.25 If-Match 14.26 If-None-Match 14.27 If-Range 14.28 If-Unmodified-Since 14.29 Last-Modified 14.30 Location 14.31 Max-Forwards 14.32 Pragma 14.33 Proxy-Authenticate 14.34 Proxy-Authorization 14.35 Public 14.36 Range 14.36.1 Byte Ranges 14.36.2 Range Retrieval Requests 14.37 Referer 14.38 Retry-After 14.39 Server 14.40 Transfer-Encoding 14.41 Upgrade 14.42 User-Agent 14.43 Vary 14.44 Via 14.45 Warning 14.46 WWW-Authenticate 15. 보안에 대한 고려 사항 15.1 클라이언트의 인증 15.2 인증 scheme을 선택할 수 있도록 함 15.3 서버 로그 정보의 남용 15.4 민감한 정보의 전송 15.5 파일 및 경로 이름에 기초한 공격 15.6 개인적인 정보 15.7 Accept 헤더와 연결된 사생활 보호의 이슈 15.8 DNS Spoofing(속이기) 15.9 Location 헤더와 Spoofing(속이기) 16. 감사의 말 17. 참고 문헌 18. 저자의 주소 19. 부록 19.1 Internet Media Type message/http 19.2 Internet Media Type multipart/byteranges 19.3 Tolerant Applications 19.4 HTTP 엔터티와 MIME 엔터티의 차이점 19.4.1 규범적인 폼으로 변환 19.4.2 날짜 형식의 변환 19.4.3 Content-Encoding 소개 19.4.4 No Content-Transfer-Encoding 19.4.5 Multipart Body-Part의 HTTP 헤더 필드 19.4.6 Transmit-Encoding 소개 19.4.7 MIME-Version 19.5 HTTP/1.0 이후 변경 사항 19.5.1 복수의 홈을 가진 웹 서버를 단순하게 하기 위한 변경 사항 및 IP 주소 보존 19.6 추가 기능 19.6.1 추가적인 요구 method 19.6.2 추가 헤더 필드 정의 19.7 이전 버전과의 호환성 19.7.1 HTTP/1.0 지속적인 연결과의 호환성
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 setof 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이 단어 또는 "요구된"이라는 형용사는 해당 항목이 규격의 절대적인 필요 조건임을 의미한다. 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에 의하여 식별되는 네트워크 데이터 객체 또는 서비스. 자원은 다양한 표현형태(예를 들어 언어, 데이터 형식, 크기 및 해상도)를 지닐 수 있으며 다양한 방법으로 변형될 수 있다. entity(엔터티)요구나 응답 메시지의 페이로드(payload)로서 전송되는 정보. 엔터티는 7 장에서 설명된 대로 Entity-Header필드 형태의 메타 정보 및 Entity-Body 형태의 내용으로 구성되어 있다. representation(표현)12 장에서 기술한 내용 협상의 통제를 따르는 응답에 포함된 엔터티. 특정한 응답 상태와 연관된 다수의표현 방법이 있을 수 있다. content negotiation(내용 협상)12 장에서 기술한 대로 요구를 처리할 때 적절한 표현 방법을 선택하는 메커니즘. 어떠한 응답에서는엔터티의 표현은 협상할 수 있다.(에러 응답 포함) variant(변형자)자원은 특정한 경우에 자원과 관련된 하나 이상의 표현 방식을 가질 수 있다. 이러한 각각의 표현 방식을"변형자"라고 부른다. "변형자"라는 용어를 사용한다고 해서 자원이 반드시 내용 협상의 대상인 것은아니다. client(클라이언트)요구 메시지를 전송할 목적으로 연결을 설정하는 프로그램. user agent(사용자 에이전트)요구 메시지를 시작하는 클라이언트. 이것은 종종 브라우저, 편집기, 스파이더(웹을 탐색하는 로봇) 또는다른 사용자 툴(tool)일 수 있다. server(서버)요구 메시지를 처리하기 위해 접속을 수신하는 애플리케이션으로서 응답 메시지를 전송한다.어떤 프로그램이든 동시에 클라이언트와 서버가 될 수 있다. 이 규격에서 이 용어를 사용하는 것은프로그램의 일반적인 능력을 참조하기보다는 특정한 연결을 위해 프로그램이 수행하는 역할만을 참조하는것이다.마찬가지로 어떠한 서버도 원서버, 프락시, 게이트웨이, 터널 등 각 요구의 성격에 따라 동작을 전환하는역할을 할 수 있다. origin server(원서버)해당 자원이 보관되어 있거나 자원을 생성할 수 있는 서버. proxy(프락시)다른 클라이언트를 대신하여 요구를 작성할 목적으로 서버와 클라이언트의 역할을 모두 수행하는 중간프로그램. 요구는 내부적으로 처리되어 가능하면 해석되어 다른 서버로 전달된다. 프락시는 이 규격의클라이언트와 서버의 필요 조건을 모두 구현해야만 한다. gateway(게이트웨이)다른 서버를 위해 중간 역할을 하는 서버. 프락시와는 달리 게이트웨이는 요구 메시지를, 요청받은자원을 서비스하는 최종적인 원서버처럼 수신한다. 요구한 클라이언트는 자신이 게이트웨이와 통신하고있다는 것을 알지 못할 수 있다. tunnel(터널)두 연결 사이를 무조건 중계하는 역할을 하는 중간 프로그램. 활성화되면 비록 HTTP 요구에 의하여시작되지만 터널은 HTTP 통신의 참여자로 간주되지 않는다. 터널은 중계하고 있는 양 쪽의 연결이종결되면 사라진다. cache(캐시)프로그램이 응답 메시지를 저장하는 로컬 저장소. 메시지 보관, 조회 및 삭제를 제어하는 하부 시스템이기도하다. 캐시는 응답 시간, 향후 네트워크 대역폭 소모 및 동일한 요구를 감소시킬 목적으로 캐시할수 있는 응답을 저장한다. 어떤 클라이언트나 서버도 캐시를 포함할 수 있다. 단지 터널 역할을 하는서버는 캐시를 사용할 수 없다. cachable(캐시할 수 있는)응답 메시지의 사본을 저장하여 계속적인 요구 응답에 사용할 수 있으면 응답을 캐시할 수 있다고 한다.HTTP 응답의 캐시 가능 여부를 결정하는 원칙은 13 장에 정의되어 있다. 자원을 캐시할 수 있다 하더라도 캐시가 특정 요구에 대하여 캐시 된 사본을 사용할 수 있는지 여부에대한 추가적인 제한 사항이 있을 수 있다. first-hand(직접)응답이 직접적으로 오며 원서버로부터 하나 또는 그 이상의 프락시를 거쳐옴으로써 발생하는 불필요한지연이 없을 경우 응답이 직접 온다고 할 수 있다. 또한 검증이 원서버에서 직접 이루어진다면 응답이직접 온다고 할 수 있다. explicit expiration time(명백한 유효 시간)원서버가 추가적인 검증 없이는 캐시에 의해 엔터티를 더 이상 되돌려 주지 않기로 한 시간. 즉, 원서버가캐시된 데이터의 유효성을 보장할 수 있는 시간. heuristic expiration time(자동으로 설정되는 유효 시간)분명한 유효 시간이 설정되어 있지 않을 때 캐시가 할당하는 유효 시간 age(경과 시간)응답 메시지의 경과 시간은 원서버로부터 전송된 후, 또는 성공적으로 검증된 후의 시간. freshness lifetime(신선한 기간)응답의 생성 시점과 유효시간 만기 시점 사이의 시간 길이 fresh(신선한)응답의 경과 시간이 신선한 기간을 넘어서지 않았을 때 응답이 신선하다고 할 수 있다. stale(낡은)응답의 경과 시간이 신선한 기간을 넘어섰다면 응답이 낡았다고 할 수 있다. semantically transparent(의미상으로 분명한)성능을 향상시키고자 하는 목적을 제외하고 캐시의 사용이 요구하는 클라이언트나 원서버에 영향을미치지 않을 때 특정한 요구에 대하여 캐시가 "의미상으로 분명하게" 작동한다고 할 수 있다. 캐시가의미상으로 분명할 때 클라이언트는 원서버가 직접 처리했을 때와 완전히 동일할 응답을 수신하게된다.( hop-by-hop 헤더는 제외). validator(검증자)캐시 엔트리가 엔터티의 복사본과 동일한지 알아내는 데 사용하는 규약 요소(예를 들면 엔터티태그나 Last-Modified 시간)1.4 Overall OperationHTTP 규약은 요구/응답 규약이다. 클라이언트는 요구 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에서는 하나의 접속을 하나 또는 그 이상의 요구/응답 교환에 사용할 수 있으나 연결이여러 가지 이유로 단절될 수 있다.( 8.1 절 참조)
2. 기호 관례 및 일반적인 문법2.1 추가된 BNF이 문서에서 명시된 모든 메커니즘은 설명형 문구로서 RFC 822 [9]에서 사용한 것과 유사한 추가된Backus-Naur Form (BNF)으로 설명되어 있다. 구현자는 이 규격을 이해하기 위하여 이러한 기호에익숙할 필요가 있다. 추가된 BNF는 다음의 구성 요소를 포함한다.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 의 경우와 같다. ","를 이용하여 나열함에 있어, nullelement가 허용된다. 예를 들어, 1#3(2DIGIT)과 같은 표현식에 대해23, , 56, 34 이렇게 null element표시가 가능하지만, 실제 갯수는 세 개로서 간주된다. 따라서 최소 한 개 최대 세 개의 제한에 위배되지않는다.; comment규칙 문장에서 오른쪽으로 약간 떨어져 있는 세미콜론은 해당 라인의 끝에까지 계속되는 주석의 시작을의미한다. 이것은 규격과 병행하여 적절한 설명을 포함시키기 위한 방법이다.implied *LWS두 개의 인접한 단어 (token or quoted-string) 또는 인접한 토큰(tokens)과 식별자 (tspecials) 사이에LWS (linear whitespace)가 포함될 수 있다. 여기서 두 개의 토큰 사이에는 반드시 적어도 하나의식별자가 존재하여 각기 하나의 토큰으로 간주되지 않게끔 구별되어야 한다.2.2 기본 규칙다음의 규칙은 기본적인 분석 구조를 설명하기 위해 이 규격 전반에 걸쳐 사용되고 있다. US-ASCII로코드화 된 문자 집합은 ANSI X3.4-1986 [21]에 의하여 규정되었다.<![CDATA[ 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 = <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를 (부록 19.3 참조) 제외한 모든 규약 요소의 라인 마감부호로 정의한다. Entity-Body 내에서의 라인 마감 부호는 3.7 절에서 설명된 것처럼 연관된 mediatype에 의하여 정의한다. CRLF = CR LFHTTP/1.1 헤더는 계속되는 라인이 스페이스나 수평 탭으로 시작한다면 복수의 라인에 걸쳐 계속작성할 수 있다. 폴딩(folding)을 포함한 모든 선형 공백 스페이스는 SP와 동일한 의미를 가진다. LWS = [CRLF] 1*( SP | HT )TEXT 규칙은 메시지 분석기가 해석하지 않도록
Posted by tornado
|
