RFC 7230 (HTTP/1.1)

JH Bang·2022년 12월 18일
0

RFC

목록 보기
1/2
post-thumbnail

RFC 7230부터 7235까지가 HTTP/1.1에 대한 문서다.
1. RFC 7230, HTTP/1.1: Message Syntax and Routing
2. RFC 7231, HTTP/1.1: Semantics and Content
3. RFC 7232, HTTP/1.1: Conditional Requests
4. RFC 7233, HTTP/1.1: Range Requests
5. RFC 7234, HTTP/1.1: Caching
6. RFC 7235, HTTP/1.1: Authentication

RFC 7230 : Message Syntax and Routing

https://www.rfc-editor.org/rfc/rfc7230

1. Introduction

HTTP에 대한 간략한 설명과 주요 표기법

ALPHA (letters)
CR (carriage return)
CRLF (CR LF)
CTL (controls)
DIGIT (decimal 0-9)
DQUOTE (double quote)
HEXDIG (hexadecimal 0-9/A-F/a-f)
HTAB (horizontal tab)
LF (line feed)
OCTET (any 8-bit sequence of data)
SP (space)
VCHAR (any visible [USASCII] character)

2. Architecture

HTTP 가 WWW 아키텍처를 위해 탄생했음을 밝힘.
Stateless 클라이언트-서버 구조와 요청/응답 구조에 대한 설명.

/****************************/
/*           URI            */ 
/****************************/
	http://www.example.com/hello.txt


/****************************/
/*      CLIENT REQUEST      */ 
/****************************/

     GET /hello.txt HTTP/1.1
     User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
     Host: www.example.com
     Accept-Language: en, mi


/****************************/
/*      SERVER RESPONSE     */ 
/****************************/

     HTTP/1.1 200 OK
     Date: Mon, 27 Jul 2009 12:28:53 GMT
     Server: Apache
     Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
     ETag: "34aa387-d-1568eb00"
     Accept-Ranges: bytes
     Content-Length: 51
     Vary: Accept-Encoding
     Content-Type: text/plain

     Hello World! My payload includes a trailing CRLF.

클라이언트는 사실상 요청하는 모든 것.
중개자(Intermediary)의 3가지 형태는 다음과 같음.

Proxy =  캐시를 사용해 효율적으로 응답
Gateway(reverse proxy) = HTTP 이외의 네트워크(사설망)와의 통로역할
Tunnel(TLS) = 안전한 통신을 위해 사용

다만 서버가 터널 역할을 하게 되면 캐시는 사용할 수 없다.

3. Message Format

HTTP 메시지 포맷에 대해 설명하는 챕터다. HTTP 메시지 파싱은 start-line을 시작으로 각 헤더 필드를 빈 행까지 읽는데, 각 헤더 필드를 해시 테이블에서 찾고 분석한다. body가 있으면 body length에 해당하는 길이를 스트림으로 읽게 된다.

     HTTP-message   = start-line
                      *( header-field CRLF )
                      CRLF
                      [ message-body ]

4. Transfer Codings

전송 코딩이란 안전한 전송을 보장하기 위해 리소스(데이터)에 적용돼야 하는 인코딩 변환 방식을 나타낸다.

헤더에 삽입되는 문법은 다음과 같다.

/*********************/
/*      REQUEST      */ 
/*********************/
TE: compress
TE: deflate
TE: gzip
TE: trailers

TE: trailers, deflate;q=0.5 // 여러 방식을 함께 기술할 때는 콤마 사용

/**********************/
/*      RESPONSE      */ 
/**********************/
Transfer-Encoding: chunked
Transfer-Encoding: compress
Transfer-Encoding: deflate
Transfer-Encoding: gzip

Transfer-Encoding: gzip, chunked // 여러 방식을 함께 기술할 때는 콤마 사용

chunked

콘텐츠의 사이즈가 큰 경우나 얼마인지 모를 때 사용되는 인코딩 방식으로 콘텐츠 크기 계산에도 시간이 걸리고 전송에도 시간이 걸리므로, 일정 크기로 잘라 전송하는 방식이다. 따라서 content-length는 헤더에서 생략된다.
서버는 크기가 0인 chunk로 콘텐츠의 끝임을 알려주고 다음 응답을 기다리거나 종료한다.

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

this is jinhyeok...\r\n
hello world~~~~~~~\r\n
hahaha\r\n
0\r\n
\r\n

compress

Lempel-Ziv-Welch (LZW) 알고리즘(압축 방식의 한 종류)을 사용한 인코딩.

deflate

Lempel-Ziv (LZ77) 압축 알고리즘과 허프만 코딩을 결합하여 사용하는 zlib 데이터 포맷 방식의 인코딩.

gzip

Lempel-Ziv (LZ77) 32비트 Cyclic Redundancy Check(CRC) 방식의 인코딩.

5. Message Routing

HTTP 요청시 주소창에 URL을 적게 되는데 이 때의 라우팅에 대해 기술하고 있다.

Inbound(클라이언트에서 서버쪽으로) 커넥션인 경우

  • 유효한 URL(URI)인지 검사
  • 캐시에 먼저 요청
  • 캐시에서 해당 응답을 못찾으면 프록시 사용
  • 프록시로도 충족되지 않으면 대상 리소스에 직접 요청

인바운드 커넥션이 형성된 뒤에 클라이언트는 URL을 4가지 방식의 포맷으로 만들어 요청 메시지를 보내게 된다.

  • origin-form
  • absolute-form
  • authority-form
  • asterisk-form

Origin-form

GET, POST, HEAD, OPTIONS 메서드와 함께 사용된다.

POST / HTTP/1.1
GET /test.png HTTP/1.0
HEAD /example.html?query=example HTTP/1.1
OPTIONS /anypage.html HTTP/1.0

Absolute-form

GET과 함께 주로 사용되며 프록시에 연결됐을 때 사용.

GET https://example.com/kor/docs/hello/world/ HTTP/1.1

Authority-form

HTTP 터널을 세팅할 때 CONNECT와 함께 사용. 포트 번호는 붙여도 되고 안 붙여도 됨.

CONNECT example.com:80 HTTP/1.1

Asterisk-form

OPTIONS 메서드와 함께 사용되며, 서버 자체를 나타낼 때 사용됨.

OPTIONS * HTTP/1.1

6. Connection Management

서버와 클라이언트의 연결을 어떤 방식으로 관리할지를 기술하는 내용이다.
Connection 헤더 필드는 커낵션이 완료된 뒤 연결을 유지할지, 끊을지를 정하게 된다.

Connection: keep-alive
Connection: close

단 keep-alive는 HTTP/1.1에서 default이다.

Connection 헤더 필드는 hop-by-hop만을 위한 헤더 필드를 end-to-end와 구분짓는다.

hop-by-hop : 데이터가 중간 노드들에게도 데이터를 전달하고 확인하며 이동되는 방식.
end-to-end : 중간 매개는 상관하지 않고 데이터를 전달하는 방식.

7. ABNF List Extension: #rule

#rule 확장은 일부 헤더 필드 값의 정의에서 가독성을 위해 사용된다.
ABNF를 사용하며 아래는 예시.

   Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
    connection-option ] )

   Content-Length = 1*DIGIT

   HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
    ]
   HTTP-name = %x48.54.54.50 ; HTTP
   HTTP-version = HTTP-name "/" DIGIT "." DIGIT
   Host = uri-host [ ":" port ]

   OWS = *( SP / HTAB )

   RWS = 1*( SP / HTAB )

   TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
   Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
   Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
    transfer-coding ] )

   URI-reference = <URI-reference, see [RFC3986], Section 4.1>
   Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )

   Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
    ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
    comment ] ) ] )

Augmented Backus–Naur Form (ABNF)은 컴퓨터 과학에서 BNF에 기초해 만든 표현 규칙이다.

Backus Naur Format이란 다음과 같이 한 필드는 오른쪽 필드로 대치될 수 있는 표기법이다. '|'는 선택을 나타낸다.

<digits>            ::= <digit> | <digits> <digit>
<digit> 	        ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

<postal-address> 	::= <name-part> <street-address> <zip-part>

<name-part>		 	::= <personal-part> <last-name> <opt-suffix-part> <EOL> | <personal-part> <name-part>

<personal-part> 	::= <initial> "." | <first-name>

[...]

8. IANA Considerations

헤더 필드 목록, URI scheme 등 에 관한 내용이다.

   /* Header Field */
   +-------------------+----------+----------+---------------+
   | Header Field Name | Protocol | Status   | Reference     |
   +-------------------+----------+----------+---------------+
   | Connection        | http     | standard | Section 6.1   |
   | Content-Length    | http     | standard | Section 3.3.2 |
   | Host              | http     | standard | Section 5.4   |
   | TE                | http     | standard | Section 4.3   |
   | Trailer           | http     | standard | Section 4.4   |
   | Transfer-Encoding | http     | standard | Section 3.3.1 |
   | Upgrade           | http     | standard | Section 6.7   |
   | Via               | http     | standard | Section 5.7.1 |
   +-------------------+----------+----------+---------------+
   | Close             | http     | reserved | Section 8.1   |
   +-------------------+----------+----------+---------------+
   
   /* URI Scheme */ 
   +------------+------------------------------------+---------------+
   | URI Scheme | Description                        | Reference     |
   +------------+------------------------------------+---------------+
   | http       | Hypertext Transfer Protocol        | Section 2.7.1 |
   | https      | Hypertext Transfer Protocol Secure | Section 2.7.2 |
   +------------+------------------------------------+---------------+
   
   /* HTTP Transfer Coding */
   +------------+--------------------------------------+---------------+
   | Name       | Description                          | Reference     |
   +------------+--------------------------------------+---------------+
   | chunked    | Transfer in a series of chunks       | Section 4.1   |
   | compress   | UNIX "compress" data format [Welch]  | Section 4.2.1 |
   | deflate    | "deflate" compressed data            | Section 4.2.2 |
   |            | ([RFC1951]) inside the "zlib" data   |               |
   |            | format ([RFC1950])                   |               |
   | gzip       | GZIP file format [RFC1952]           | Section 4.2.3 |
   | x-compress | Deprecated (alias for compress)      | Section 4.2.1 |
   | x-gzip     | Deprecated (alias for gzip)          | Section 4.2.3 |
   +------------+--------------------------------------+---------------+
   
   /* Content Coding */
   +------------+--------------------------------------+---------------+
   | Name       | Description                          | Reference     |
   +------------+--------------------------------------+---------------+
   | compress   | UNIX "compress" data format [Welch]  | Section 4.2.1 |
   | deflate    | "deflate" compressed data            | Section 4.2.2 |
   |            | ([RFC1951]) inside the "zlib" data   |               |
   |            | format ([RFC1950])                   |               |
   | gzip       | GZIP file format [RFC1952]           | Section 4.2.3 |
   | x-compress | Deprecated (alias for compress)      | Section 4.2.1 |
   | x-gzip     | Deprecated (alias for gzip)          | Section 4.2.3 |
   +------------+--------------------------------------+---------------+

인터넷 미디어 타입 : http://www.iana.org/assignments/media-type

9. Security Considerations

HTTP 보안과 관련된 내용으로 메시지 구문, 구문 분석 및 라우팅과 관련된다.

HTTP entity

간혹 HTTP entity라는 용어가 보인다. 이는 RFC 2616에서 정의한 용어로 Entity = Entity header + Entity body이다. 하지만 현재 HTTP/1.1을 기술하는 문서인 7230~7235에서는 entity에 대해 언급하고 있지 않다.

참고로만 entity가 뭔지 알아보자면, Entity header는 Content-Length, Content-Language, Content-Encoding, Content-Type, Expires 등을 포함한다.

/*********************/
/*      REQUEST      */ 
/*********************/

POST /foo HTTP/1.1          // <- entity가 아님
Host: example.com			// <- entity가 아님
Content-Type: text/plain    // ⎞ 
Content-Length: 1000        // ⎟ entity
                            // ⎟
Hello World ...             // ⎠


/**********************/
/*      RESPONSE      */ 
/**********************/

HTTP/1.1 200 OK             // <- entity가 아님
Content-Length: 42          // ⎞
Content-Type: text/plain    // ⎟  entity
                            // ⎟
Response body ...           // ⎠

참고 : https://developer.mozilla.org/en-US/docs/Web/HTTP

profile
JH Bang
의지와 행동
다음 포스트

RFC 7231 (HTTP/1.1)

0개의 댓글

관련 채용 정보