web-dev-qa-db-ja.com

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

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

長所：

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

短所：

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

ポイント：

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

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

httphttp-headersheaders
12
Metalshark

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

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

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

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

ユースケースに依存すると言うでしょう：

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

MD5チェックにより、Webページのロード時間が遅延します。

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

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

1
Kris