HTTP Content-MD5ヘッダーの考慮事項

Content-MD5ヘッダーを使用するかどうかを検討しています。

長所：

• CMSを使用すると、オーバーヘッドを最小限に抑えて簡単に含めることができます（ケースの80％以上でキャッシュされた応答）。
• 問題に対する別の保護層が追加されます。

短所：

• Content-Lengthヘッダーは常に（動的に作成されたページ上にも）存在するため、クライアントは別の形式の検証を必要としません。
• これまでのところ、破損が原因で発生する問題は認識していません。
• MD5チェックは、Webページのロード時間に遅延を追加します。

ポイント：

• 特定のメディアタイプには、これを不要にする独自の形式のダイジェストが含まれていますか？
• TCPがすでにこれを提供している場合、なぜHTTP標準に含まれていたのですか？
• 既存の実際の用途は何ですか？
• MD5チェックは無視できますか？

これを単体テストに追加して実装することは、実際の問題ではありません。1時間程度の作業です。ただし、有害な場合は、Webサイトの「ヘルスチェック」で使用される高レベルのスニフテストに追加する必要があります。

TCPにはすでにエラー修正機能がありますが、これはTCP層でのみ役立ちます。中間のHTTPプロキシまたはロードバランサーは、HTTPレイヤーのデータを破損してから再送信する可能性があります。HTTP MD5は、この破損を検出することを可能にします。この必要性について誰も実際に話さない理由は、問題が実際に非常にまれだからです。ほとんどのHTTPプロキシなどは「動作する」だけです。

RFCはセキュリティを暗示しています。私見これは非常に弱いので無視する必要があります-何らかの種類のセキュリティと機密性が必要な場合は、HTTPSが必要です。

特定のメディアタイプには、これを不要にする独自の形式のダイジェストが含まれていますか？

本当に良いものではありません。しかし、写真やストリーミングビデオなどのいくつかのビットエラーは、人間にはほとんど認識されません。

私はそれがユースケースに依存すると言うでしょう：

• RESTベースのWebサービスの場合、ダイジェストは追加のエラー修正の便利なレイヤーを追加します。例として、このAWSの失敗を参照してください。
• プレーンHTTPでミッションクリティカルなデータを扱うアプリケーションの場合、実装する価値があります。Content-MD5は、エンドツーエンドの伝送の整合性を検証するオプションをクライアントに提供します。
• 「通常の」値のテキストとメディアを提供する「通常の」Webサイトの場合、Content-MD5ヘッダーは目的を果たしません。そして、正直に言って、実際にいくつの主流ブラウザー（PC、特にモバイル）が実際にそれをサポートしているかさえ知りません。

MD5チェックは、Webページのロード時間に遅延を追加します。

本当なら（そして待ち時間は完全に些細ではない）、私はそれが価値がなかったと言うでしょう。

一般に、最後に変更されたヘッダーは、ページが変更されたかどうかを判断するために最も一般的に使用されると考えています。そこに意味のある値を提供すると仮定すると、content-md5ヘッダーは必要ありません。