HTTP 1.1

https://tools.ietf.org/html/rfc2616 을 읽고 HTTP 1.0과 다른점에 대해서 알아봅시다.

1 Introduction

1.1 Purpose

HTTP/0.9 원래 데이터(raw data)를 전송하기 위한 단순한 프로토콜입니다.

HTTP/1.0 전송되는 문서 데이터에 대한 메타 정보 추가, 요청/응답를 포함하는 MIME과 유사한 메시지의 형식으로 사용 가능하게 프로토콜 확장했지만 계층적 프록시, 캐시, 지속적인 연결의 필요성 및 가상 호스트 등의 영향을 충분히 고려하지 않았습니다.

MIME 다용도 인터넷 메일 확장

1.2 Requirements (pass)

1.3 Terminology
http 1.0에 없는 것들만 적겠습니다.

1. content negotiation 내용 협상
   요청을 처리할 때 적절한 표현 방법을 선택하는 방법입니다. 
2. variant 변형자
   자원은 특정한 경우에 자원과 관련된 하나 이상의 표현 방식을 가질 수 있습니다. 이러한 각각의 표현 방식을 "변형자"라고 합니다. "변형자"라는 용어를 사용한다고 반드시 내용 협상의 대상인 것은 아닙니다.
3. cachable 캐시할 수 있는
   응답 메시지의 복사본을 저장하여 계속적인 요청에 응답으로 사용할 수 있으면 cachable이라고 합니다. 
4. first-hand 직접
   응답이 직접적으로 오며 origin-server로 부터 하나 또는 이 이상의 프록시를 거쳐옴으로써 발생하는 불필요한 지연이 없을 경우 응답이 first-hand하다고 할 수 있습니다.  
5. explicit expiration time 명백한 유효 시간
   origin server가 캐시된 데이터의 유효성을 보장할 수 있는 시간입니다.
6. heuristic expiration time 자동으로 설정되는 유효 시간
   명백한 유효 시간이 설정되어 있지 않은 경우 캐시에 의해 자동으로 설정되는 유효 시간입니다.
7. age 경과 시간
   응답 메시지의 경과 시간은 origin server로 부터 전송된 후, 또는 성공적으로 검증된 이 후의 시간입니다.
8. freshness lifetime 신선한 시간
   응답의 생성 시점과 유효시간 만기 시점 사이의 시간입니다.
9. fresh
   응답의 경과 시간이 신선한 기간을 넘어서지 않았을 때 신선(fresh)하다고 합니다.
10. stale 낡은
    응답의 경과 시간이 신선한 기간을 넘어 섰을 때 낡았(stale)다고 할 수 있습니다.
11. semantically transparent 의미상으로 분명한
    성능 향상 목적을 제외하고 캐시의 사용이 클라이언트나 서버에 영향을 미치지 않을 때 특정한 요구에 대해서 캐시가 "의미상으로 분며하게" 작동한다고 할 수 있습니다. 캐시가 의미상으로 분명할 때 클라이언트는 원서버가 직접 처리했을 때와 동일한 응답을 수신하게 됩니다.
12. validator 검증자
    캐시 엔트리가 엔티티의 복사본과 동일한지 알아내는 데 사용하는 프로토콜 요소.(ex, 엔티티 태크, Last-Modified 시간)

1.4  Overall Operation (pass)

2 Notational Conventions and Generic Grammar (pass)

3 Protocols Parameters

3.5 Content Codings

deflate
"deflate" 압축 메커니즘과 결합하여 정의된 "zlib" 포맷입니다.

3.6 Transfer Codings

Transfer Codings의 값은 네트워크를 통한 "안전 전송"을 확보하기 위해 Entity-Body에 적용하거나, 적용할 수 있거나 또는 적용할 필요가 있는 인코딩 변호나을 표시하는 데 사용합니다. Content codings와 다른점은 메시지의 특성 중의 하나이며 원래 엔티티의 특성이 아니라는 점입니다.

transfer-coding = "chunked" | transfer-extension
transfer-extension = token

모든 transfer-coding 값은 대소문자를 구별하지 않습니다. 7비트 전송 서비스로 바이너리 데이터를 안전하게 전송할 수 있도록 디자인된 MIME의 Content-Transfer-Encoding과 유사합니다. 그러나 8 비트 전송 규약에서 안전 전송의 중점은 다른 곳에 있습니다. HTTP에서 유일하게 content-length를 결정하기 어려운 것과 공유하는 전송체계에서 데이터를 암호화 하기 어렵다는 것입니다. 서버가 Transfer-Coding을 해독하지 못 한다면 501 응답을 합니다.

 

3.7 Multipart Type

MIME는 많은 "multipart"형식을 제공하고 있는데 하나 또는 그 이상의 엔티티를 단일 메시지 본문 내에 포함시킬 수 있도록 하는 것이다. 

 

4. HTTP Message