6月 132019
目次
概要
参照 RFC7230 4, 3.3.1
- HTTP メッセージボディーの転送は、HTTP/1.0 までは Content-Length で指定した長さのデータを転送する方式しかなかった
- 転送が終わるまでボディーデータの全てをメモリ上にとどめておく必要があるなどした
- HTTP/1.1 にて chunked transfer coding (chunked) ができるようになり、ボディーデータを分割して転送することができるようになった
- 事前に最終的な長さが分からなくても転送可能
- HTTP/2 には Transfer Codings の仕組み自体がない
- Stream に取って代わられたため
- Transfer Codings の方式は、TE および Transfer-Encoding ヘッダーにて指定する
- TE ヘッダーでクライアントが受入可能な方式を指定
- Transfer-Encoding ヘッダーで送信するメッセージの符号化方式を指定
- 受信者は chunked を復号化できなければならない [RFC7230 4.1]
- Transfer-Encoding は hop-by-hop ヘッダーであり、隣接ノード間にのみ適用される [RFC7230 3.3.1]
- 故に、プロキシなどの中継者は Transfer-Encoding を復号化し、Content-Length 方式や別の Transfer-Encoding に変換するなどしても良い
- Content-Encoding ヘッダーは end-to-end ヘッダーである点に注意
chunked transfer coding
参照 RFC7230 4.1
以下のような形式で分割送信される。
HTTP/1.1 200 OK
Date: Thu, 20 Sep 2018 01:59:09 GMT
Transfer-Encoding: chunked
c
example data
4
hoge
0
Expires: Wed, 21 Oct 2015 07:28:00 GMT
- チャンクサイズ(16進数文字列) + CRLF を送信
- チャンクデータ + CRLF を送信
- それ以上データがなければ 0 + CRLF を送信
- Trailer ヘッダーがあれば送信
- CRLF で終端
TE, Trailer
参照 RFC7230 4.3, 4.4
- 上記の通り、ボディーデータの後にトレイラーヘッダーが付加されることがある
- 受信者がトレイラーヘッダーを許容するつもりがある場合、TE ヘッダーに
trailersを指定する[RFC7230 4.3] - chunked 方式は必須実装であるため、TE ヘッダーはそれ以外の方式を指定する場合に用いられる
- トレイラーヘッダーの受信者は、それらが HTTP メッセージのヘッダーに付加されていたかのように処理して良い [RFC7230 4.1.2]
- 一部のヘッダーは禁止されており、無視しなければならない
- HTTP/2 にもトレイラーヘッダーの概念は存在する
Compression Codings
参照 RFC7230 4.2
- chunked 以外にも圧縮を用いる Transfer Codings を指定できる
cmopress,deflate,gzip
- 利用する場合、クライアントは TE ヘッダーにて利用できることを示さなければならない
- Transfer-Encoding で指定された順序で Encoding されている [RFC7230 3.3.1]
Transfer-Encoding: gzip, chunkedなら、gzip 圧縮された上で chunked されている事を示す- chunked を複数回適用することはできない
HTTP メッセージボディーの長さ
参照 RFC7230 3.3.3, 3.4
- かなり細かいので詳細は RFC 参照
- Transfer-Encoding がある場合はそれを使用して判断する
- Transfer-Encoding があり、chunked ではないレスポンスの場合は Close により終端が決定される
- Transfer-Encoding があり、chunked ではないリクエストの場合は 400 Bad Request として処理しなければならない
- Transfer-Encoding がない場合は Content-Length を使用する