> For the complete documentation index, see [llms.txt](https://hochan049.gitbook.io/cs-interview/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hochan049.gitbook.io/cs-interview/web/rfc-7320/appendix-a.-http-version-history.md).

# Appendix A. HTTP Version History

HTTP는 1990년부터 사용되고 있다. 나중에 HTTP/0.9 라고 불리는 첫 번째 버전은 단일 요청 메서드(GET)만 사용하고 메타데이터는 사용하지 않는 인터넷을 통한 하이퍼텍스트 데이터 전송을 위한 간단한 프로토콜이었다. \[RFC1945]에서 정의한 대로 HTTP/1.0은 다양한 요청 메서드와 MIME 유사 메시지를 추가하여 메타데이터를 전송하고 요청/응답 의미론에 수정 자를 배치할 수 있도록 했다. 그러나 HTTP/1.0은 계층 프락시, 캐싱, 영속적 커넥션의 필요성 또는 이름 기반 가상 호스트의 영향을 충분히 고려하지 않았다.

HTTP/1.1은 신뢰할 수 있는 구현을 가능하게 하는 보다 엄격한 요구사항을 포함하므로써 HTTP/1.0과 호환성을 유지하며, HTTP/1.0 수신자가 안전하게 무시하거나 HTTP/1.1과 통신할 때에만 전송할 수 있는 기능만 추가한다.

HTTP/0.9는 요청에서 헤더 필드를 지원하지 않았기 때문에 이름 기반 가상 호스트(Host 헤 더 필드의 검사에 의한 리소스 선택)를 지원하는 메커니즘이 없다. 이름 기반 가상 호스트를 구현하는 모든 서버는 HTTP/0.9에 대한 지원을 비활성화해야 한다. HTTP/0.9로 보이는 대부분의 요청은 실제로 클라이언트가 요청 대상을 제대로 인코딩하지 못해 발생하는 잘못 구성된 HTTP/1.x 요청이다.

#### A.1 Changes HTTP/1.0

이 섹션은 버전 HTTP/1.0과 HTTP/1.1 사이의 주요 차이점을 요약한다.

#### A.1.1 Multihomed Web Servers

클라이언트와 서버가 Host 헤더 필드를 지원하고(Section 5.4), HTTP/1.1 요청에 누락된 경 우 오류를 보고하고, 절대 URI를 수락(Section 5.3)하는 요건은 HTTP/1.1에서 정의한 가장 중요한 변경 사항 중 하나이다.

#### A.1.2 Keep-Alive Connections

HTTP/1.0에서 각 커넥션은 요청 전에 클라이언트에 의해 설정되고 응답 전송 후 서버에 의해 종료된다. 그러나 일부 구현에서는 명시적으로 협상된 \[RFC2068] Section 19.7.1에 설명한 영속적 커넥션(“Keep-Alive”) 버전을 구현한다.

일부 클라이언트와 서버는 "Connection: keep-alive" 요청 헤더 필드와 명시적으로 협상함으로써 영속적 커넥션에 대한 이러한 이전 접근방식과 호환되기를 원할 수 있다. 그러나 HTTP/1.0 영속적 커넥션의 일부 실험적 구현은 결함이 있다. 예를 들어 HTTP/1.0 프락시 서버가 Connection을 이해하지 못하면 헤더 필드를 다음 인바운드 서버로 잘못 전달하여 커넥션이 끊어질 수 있다.

클라이언트는 또한 요청에서 keep-alive 커넥션을 주의깊게 사용하도록 권장된다: 그들은 HTTP/1.0 서버와의 영속적 커넥션을 가능하게 할 수 있지만, 클라이언트가 “hung” 요청의 커넥션을 감시해야 할 필요가 있을 것이다.(헤더 필드 전송을 중단해야 한다는 것을 나타내는) 그리고 프락시를 사용할 때 이 메커니즘은 클라이언트에 의해 사용되어서는 안 된다.

#### A.1.3 Introduction of Transfer-Encoding

HTTP/1.1에는 Transfer-Encoding 헤더 필드가 도입된다(Section 3.3.1). 전송 코딩은 MIME 호환 프로토콜을 통해 HTTP 메시지를 전달하기 전에 해독되어야 한다.

#### A.2 Changes from RFC 2616

오류 처리에 대한 HTTP의 접근방식이 설명되었다. (Section 2.5)

HTTP-version ABNF은 대소문자를 구분하는 것으로 명확해졌다. 또한 버전 번호는 구현 시 여러 자릿수의 버전 번호를 잘못 취급하는 것으로 알려져 있기 때문에 한 자릿수로 제한되어 왔다. (Section 2.6)

Userinfo(즉, 사용자 이름 및 암호)는 현재 유/무선상의 전송과 관련된 보안 문제로 인해 HTTP 및 HTTPS URIs에서 허용되지 않는다. (Section 2.7.1)

HTTPS URI scheme는 이제 이 명세에 의해 정의된다. 이전에는 \[RFC2818]의 Section 2.4에서 수행되었다. 추가로, 그것은 end-to-end 보안을 의미한다. (Section 2.7.2)

HTTP 메시지는 구현에 의해 버퍼링될 수 있으며(그리고 종종) 스트림으로 이용 가능함에도 불 구하고 HTTP는 근본적으로는 메시지 지향 프로토콜이다. 상호운용성을 개선하기 위해 다양한 프로토콜 요소에 대해 지원되는 최소 크기가 제안되었다. (Section 3)

field-names 주변의 잘못된 공백을 수락하면 보안 취약성을 나타내기 때문에 잘못된 공백은 거부되어야 한다. 헤더 필드를 정의하는 ABNF은 이제 필드 값만 나열한다. (Section 3.2)

특정 문법 제작 사이의 암시적 선형 공백에 대한 규칙은 제거되었다. 이제 공백은 ABNF에 특별히 정의된 경우에만 허용된다. (Section 3.2.3)

여러 라인에 걸쳐 있는(“line folding”) 헤더 필드는 더 이상 사용되지 않는다. (Section 3.2.4)

정확히 언제 “close” 커넥션 옵션을 보내야 하는지가 명확해졌다. 또한 “hop-by-hop”헤더 필드는 Connection 헤더 필드에 나타나야 한다. 단지 이 항목에서 hop-by-hop으로 정의된다고 해서 제외되는 것은 아니다. (Section 6.1)

서버당 두 개의 커넥션 한도가 제거되었다. 멱등성인 요청 시퀀스는 더 이상 재시도할 필요가 없다. 서버가 커넥션을 조기에 종료할 때 특정 상황에서 요청을 다시 시도해야 하는 요구 사항이 제거됨. 또한, 서버가 언제 조기에 커넥션을 닫을 수 있는지에 대한 일부 관련 요구사항이 제거되었다. (Section 6.3)

Upgrade 헤더 필드의 의미론은 이제 101이 아닌 다른 응답으로 정의된다(이것은 \[RFC2817]에서 통합되었다). 게다가, 필드 값의 순서는 이제 중요하다. (Section 6.7)

HTTP/0.9 요청을 지원하려는 기대가 제거되었다. (Appendix A)

요청에서 Keep-Alive 및 Proxy-Connection 헤더 필드의 문제가 지적되며, 후자의 사용은 전히 중단된다. (Appendix.A 1.2)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://hochan049.gitbook.io/cs-interview/web/rfc-7320/appendix-a.-http-version-history.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.