[13] [[HTTP/2]] のいくつかの[[フレーム]]では、 [[payload]]
に実際の長さを隠すための[DFN[[RUBYB[[[詰め物]]]@en[padding]]]]を挿入することができます。

* 仕様書

[REFS[
- [2] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-6.1>
- [14] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-6.2>
- [15] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-6.6>
- [36] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-10.7>
]REFS]

* 構文

[3] [CODE(HTTP)@en[[[DATA]]]] [[フレーム]] [SRC[>>2]] や
[CODE(HTTP)@en[[[HEADERS]]]] [[フレーム]] [SRC[>>14]] や
[CODE(HTTP)@en[[[PUSH_PROMISE]]]] [[フレーム]] [SRC[>>15]]
には、 [DFN[[RUBYB[[[詰め]]]@en[Padding]]]]欄があります。
これは[[メッセージ]]の長さを隠すための[[セキュリティー]]機能です [SRC[>>2]]。

[4] [[送信者]]は、[[詰め]]をすべて 0 の[[オクテット]]にしなければ[['''なりません''']]
[SRC[>>2]]。

;; [5] [[詰め長]]欄の長さより、[[詰め]]欄の最大長は、255バイトです。

[9] [CODE(HTTP)@en[[[DATA]]]] [[フレーム]] [SRC[>>2]] や
[CODE(HTTP)@en[[[HEADERS]]]] [[フレーム]] [SRC[>>14]]
には、[DFN[[RUBYB[[[詰め長]]]@en[Pad Length]]]]欄があります。
これは[[詰め]]の長さを[[バイト]]単位で8ビットで表したものです [SRC[>>2, >>14, >>15]]。

[6] [[詰め長]]欄 (と[[詰め]]欄) は、 [CODE[[[PADDED]]]] 
フラグが設定されている場合のみ存在します [SRC[>>2, >>14, >>15]]。

;; [7] 値は0でも構いません。値が実際の[[詰め]]の長さを超えることは禁止されていませんが、
当然正しく処理できませんし、[[payload]] の長さを超えるなら[[接続エラー]]となります。

[12] [CODE(HTTP)@en[[[DATA]]]] [[フレーム]]や
[CODE(HTTP)@en[[[HEADERS]]]] [[フレーム]]の
[DFN[[CODE[[[PADDED]]]]]] ([CODE[[[0x8]]]] = 第3ビット) フラグは、
設定されていれば[[詰め長]]と[[詰め]]の欄が含まれることを表します。 [SRC[>>2, >>14, >>15]]

* 文脈

[38] [[詰め]]は、[[フレーム]]の内容の実際の大きさを隠し、 [[BREACH攻撃]]などを難しくするために使うことができます。 [SRC[>>36]]

[39] しかしこれは [[TLS/1.2]] などのような一般目的の詰めの代替を意図したものではありません。
[SRC[>>36]]

[40] 適切に扱うためには、詰めを追加する対象のデータの性質を知っている必要があります。
また詰めによる防御効果は見かけより少なく、攻撃者が観測しなければならない[[フレーム]]の数を多少増やす程度かもしれません。
適切に実装されなければ、詰めの方法は簡単にわかってしまうかもしれません。 [SRC[>>36]]

[41] [[圧縮]]を使った攻撃を防ぐには、詰めを使うのではなく、
[[圧縮]]を無効にしたり制限したりする方が適切かもしれません [SRC[>>36]]。

* 処理

[8] [[詰め]]と [[payload]] の長さに関する問題は、エラーとなります。

;; [CODE(HTTP)@en[[[DATA]]]] [[フレーム]]の処理の項を参照。

[11] [[受信者]]は、[[詰め]]に 0 以外があれば[[接続エラー]] [CODE[[[PROTOCOL_ERROR]]]]
としても構いません。 [SRC[>>2]] 

;; [10] [[相互運用性]]の問題が生じるかもしれませんし、実装により扱いが異なるのは
[[fingerprinting vector]] かもしれません。

[42] [[中間器]]は [CODE[[[DATA]]]] [[フレーム]]の[[詰め]]を残す[['''べき''']]ですが、
[CODE[[[HEADERS]]]] や [CODE[[[PUSH_PROMISE]]]] では削っても構いません。 [SRC[>>36]]

;; [1] [[ヘッダーブロック]]は再符号化が必要なので、 [[payload]]
の状態をそのまま[[転送]]する必要もないからでしょう。

[16] [CITE[Implement padding PUSH_PROMISE and HEADERS frames. (issue 661743003 by b...@chromium.org) - Google Groups]]
([TIME[2015-10-12 18:35:55 +09:00]] 版)
<https://groups.google.com/a/chromium.org/forum/#!topic/chromium-reviews/147G5N9izTw>