PEAR::HTTP_Requestは自動的にchunkedを処理してくれる(ようだ(と思う

恥ずかしながら、HTTP/1.1でリクエストする際にPEARのHTTP_Requestが"Transfer-Encoding: chunked"を暗黙的に処理してくれているのか確認していませんでした。

サーバは、TE フィールドによって与えられた転送コーディングが受け入れ可能かを試すために、以下の規則を使う事ができる。

1."chunked" 転送コーディングは常に受け入れ可能である。"trailers" というキーワードが列挙されていれば、クライアントは、自身やダウンストリームのクライアントがチャンク形式のレスポンス中の trailer フィールドを受け入れ可能である、という事を示す。このフィールドが与えられた場合、クライアントは、すべてのダウンストリームクライアントは転送されるレスポンス中の trailer フィールドを受け入れ可能であるか、あるいはダウンストリームの受信者のためにレスポンスをバッファしようとしているか、のどちらかを示している事を意味する。

注: HTTP/1.1 は、クライアントがレスポンス全体のバッファリングを保証できるようなチャンク形式レスポンスのサイズの制限するための手段を定義しない。

2.現在試している転送コーディングが TE フィールド内に列挙されている転送コーディングの一つで、その qvalue が 0 でなければ、受け入れ可能である。(section 3.9 にて定義されるように、qvalue が 0 であるという事は、"受け入れ不可能" を意味する。)

3.複数の転送コーディングが受け入れ可能である時は、qvalue が 0 以上で最も大きい値を持つ転送コーディングが優先される。"chunked" 転送コーディングの qvalue は常に 1 である。

TE フィールド値が空か、あるいは TE フィールドが与えられていなければ、使用できる転送コーディングは "chunked" のみとなる。転送コーディングがなされていないメッセージは、常に受け入れ可能である。

TE :: ハイパーテキスト転送プロトコル -- HTTP/1.1

多分、chunkedは常に受け入れなければいけないような気がしています。qvalueを0にしたら受け入れ不可能となるのでしょうか?

とりあえず、HTTP_RequestではTransfer-Encodingが存在するレスポンスに対して特別な処理をしており、 その値がchunkedであればchunkedなデータの読み取りをしているようです。まあ、deflate問題の様に値を"==chunked"で比較しているので、複数の値が指定された場合にどうなるかは不明ですがね。

ひとまず、(大半の)予期しないchunked(?)については勝手に処理してくれるものだと考えておきます。

プロフィール

このブログ記事について

このページは、koshigoeが2007年9月 3日 22:01に書いたブログ記事です。

ひとつ前のブログ記事は「PHPの日付関数の定数は使いやすいのか」です。

次のブログ記事は「"Transfer-Encoding: gzip"について諦めカウントダウン」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。