仕様書

プロトコル

[3] RFC 3229 は HTTP の標準のキャッシュの更新の仕組み (条件付き要求) は 100% (200) と 0% (304) の転送しかなく、実際には部分的な更新のことが多いため効率的ではないとして、 差分のみを転送する仕組みを提案していました。

[4] ただし同 RFC はそのために差分のみならず範囲要求や圧縮も統合した実現値操作なる概念を導入するよう HTTP のプロトコルに過大に手を入れるものでした。

[5] 差分符号化では次のプロトコル要素が使われます。

[7] RFC 3229 は差分符号化法として diff -e、diff -e + gzip、 vcdiff を紹介しつつ、特定の方法を推奨するものではなく、とはいえ A-IM: が長くなるのは好ましくないことから一定期間後に推奨形式を決めるべき >>6 と述べていました。

[17] 差分符号化は、2入力の実現値操作です >>18。

[26] 次の項目も参照。

差分符号化の一覧

[10] 差分符号化は実現値操作のうち次のものとされています >>9。

処理モデル

[12] 鯖は、次の条件をすべて満たす時、差分符号化した応答を返さなければなりません >>11。

[16] 差分符号化された応答は、 226 状態符号を使わなければなりません >>11。

[19] キャッシュにおける処理については、226 を参照。

[20] 内容符号化との関係については、内容符号化を参照。

歴史

[21] 差分符号化を含む実現値操作は、関連仕様の RFC 3230 と共に、 平成14(2002)年に RFC 3229 として出版されました。

[22] 同時期に開発されていた差分符号化法である VCDIFF も少し遅れて RFC 3284 として出版されています。

[23] しかしこれらはその当初の規定の範囲ではほとんど実装されませんでした。 VCDIFF が特許問題により忌避されたこと、 実現値操作の仕組みが複雑なこと、 差分の生成のために過去の基底実現値を (すべてでは無いにせよ、十分多く、 十分長期間) 保持し続けなければならないこと (鯖もキャッシュも。)、 といった課題に対して、差分によって転送量を削減することによる費用対効果が本当にあったのかは、 平成14(2002)年時点でも疑問が残ります。

[24] 平成16(2004)年頃の Web 2.0 時代、 フィードのページングの指定手法として注目されることになります。 これは要求に A-IM: feed と指定することにより、 フィードに含まれるエントリーのうち If-None-Match: で指定された時点より後のもののみを応答に含めることを求めるものでした。 A-IM: feed

[25] この手法はフィードリーダーやフィードを提供する鯖には比較的広く実装されました。 しかしフィードに特化した方式であり、その他の汎用的な実装には広まってゆきませんでした。 そのため、 Web 2.0 ブームの終焉により、実装も利用頻度も減少していると思われます。

[901] 120393 – [RFE] support Proposed Standard Protocol RFC 3229: Delta encoding in HTTP (compatible extension to HTTP/1.1) ( (2014-11-23 00:53:57 +09:00 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=120393

[902] Efficiently compressing dynamically generated web content ( (2014-11-23 00:56:53 +09:00 版)) http://blog.cloudflare.com/efficiently-compressing-dynamically-generated-53805/