Dev Study
← 解説「レスポンスの分解 — status-line、field-line、そして本文の長さをどう決めるか」に戻る

サンプルコードで身につける: レスポンスの分解 — status-line、field-line、そして本文の長さをどう決めるか

解説で学んだ概念を、3つの具体例で確認します。素朴な例から実務寄りの例へと進みます。

1status-line と field-line を手で分ける

レスポンスは最初の空行で部とに分かれます。1 行目の は splitn(3, ' ') で 3 つまで(reason-phrase には空白が入る)、残りの field-line は最初の ':' だけで分けます(Date の値にも ':' が入る)。実行すると version= code=200 reason="OK"、ヘッダー 3 行、本文 "<p>hello</p>" が 12 バイトと出ます。

Rust

2HttpResponse::parse: 本文の長さと LF 許容

HttpResponse::parse の縮小版で、本文の長さは 9112 6.3 の順で ()を より先に見て、どちらも無ければ受け取った全部とします。行末は が正式ですが 2.2 に従って だけの行も受け付け、header() は名前の大文字小文字を区別しません(RFC 9110 5.1)。実行すると 7 本のうち 3 本が ok(Content-Length 5 で "hello world" が "hello" に切られる、LF だけの 404、chunked が "hello, world" に復元される)、4 本が gzip・壊れたヘッダー・ステータス行無し・空の理由で NG になります。

Rust

3実務: レスポンスのダンプで宣言と実際の長さを比べる

curl -i やプロキシのログに残ったレスポンスを読み、Content-Length の値と本文の実際のバイト数を比べる検査です。Content-Length はバイト数で文字数ではないので「こんにちは」は 15 バイト(5 文字)で一致し、1024 バイト宣言で 22 バイトしか無いダンプは「1002 バイト足りない(途中で切れた可能性)」、5 バイト宣言に 34 バイトあるダンプは「29 バイト余っている(次のレスポンスが続いている)」、chunked は「長さの宣言が無い」、空行の無いものは区切り無しと判定されます。切れたレスポンスの調査で最初に見る数字です。

Rust

図やコードに出てくる用語(タップで説明)