ビデオと字幕 · ダイレクト メディア ダウンローダー
MIME タイプと Content-Type: Web がダウンロード用のメディア ファイルにラベルを付ける方法
· 背景
http メディア Web の基本
拡張子はファイル名の規則です。 MIME タイプは、サーバーがブラウザにファイルが何であるかを伝える方法です。この記事では、MIME タイプの由来、Content-Type がダウンロードをどのように形成するか、および 2 つが一致しない場合に何が起こるかについて説明します。
ファイルは .mp4 と呼ばれますが、ブラウザはそれをテキストとして扱います。これは、MIME タイプが防ぐために設計された不一致です。
`.mp4` で終わるパスはテキストとして提供できますが、サフィックスのないパスは有効なビデオを伝送できます。拡張子は名前に属します。 HTTP Content-Type は応答メタデータに属します。
ダイレクト メディア ダウンローダーは、CORS がヘッダーを公開するときの HEAD 中にそのヘッダーを読み取り、再度 GET から読み取ります。値を表示し、それを BLOB タイプとして使用し、メディアに見える値をブロッキング証明書ではなくアドバイスとして扱います。したがって、ヘッダーが間違っていると、特に応答がインラインで表示される場合に、プレイヤーがペイロードを調べる前に動作が変わる可能性があります。不正確なラベルは、特にブラウザがメディアをインラインでレンダリングする場合、プレーヤーが本文を検査する前の処理に影響を与える可能性があります。
電子メールの添付ファイルから HTTP へ — MIME タイプが電子メールの部分にラベルを付ける方法として始まり、Web のファイルラベル付けシステムになった経緯
MIME はメッセージ部分にラベルを付けるためのシステムとして始まり、HTTP で表現に使用される語彙になりました。メディア タイプにはトップレベルのタイプとサブタイプがあり、その後にオプションでパラメータが続きます。
ラベルはブラウザが処理を選択するのに役立ちますが、それを制御するのは送信サーバーです。メタデータが貧弱なストレージ バケットは、役に立たない汎用値の下で正しいバイトを提供できます。 HTTP がレジストリを採用したのは、すべてのクライアントがファイル名や文書化されていないバイト推測から意味を考え出すよりも、相互運用可能なラベルの方が望ましいためです。共有登録により、互換性のないプライベート命名規則が、メールおよび Web クライアントが一貫して解釈できるラベルに置き換えられました。
Content-Type ヘッダーの読み取り — タイプ、サブタイプ、パラメーター。一般的なケースとして video/mp4, audio/mpeg および application/octet-stream を使用します。
`video/mp4` は MP4 メディア表現を記述し、`audio/mpeg` は MPEG オーディオを記述し、`application/octet-stream` は汎用バイナリ ラベルです。 charset パラメータはテキストに共通ですが、メディア コーデックを識別しません。
ToolAcre は完全なヘッダー文字列を保存します。その `looksLikeMedia` アドバイザリは、ビデオ、オーディオ、および MPEGURL ラベルを認識します。オクテット ストリームは自動的に拒否されずに警告を引き起こします。パラメータはメディア タイプの仕様に従って解釈される必要があります。それらが存在するだけでは、あるトップレベルの型が別のトップレベルの型に変換されるわけではありません。パラメータは、該当する型定義に基づいて読み取られる必要があります。それらの存在によって、バイナリ応答が別のトップレベル ファミリに変更されることはありません。
スニッフィングとその制限 — ブラウザーが推測することがある理由と、その推測が間違っていたり、意図的に無効にされたりする理由
ブラウザーは、メタデータが欠落しているか曖昧な場合にバイトを検査することがありますが、スニッフィングはセキュリティと一貫性のために制限されています。サーバーは一部の推測を無効にすることができ、動作はコンテキストによって異なります。
ダウンローダーは独自の署名スキャナーを実装しません。コーデックを調べた後にコンテナを開いたり、宣言された MIME をオーバーライドしたりすることはないため、ホストのメタデータを修正すると主張することは避けてください。 `X-Content-Type-Options: nosniff` などのセキュリティ ヘッダーは、推測を意図的に制限し、正確なサーバー構成に大きな責任を課すことができます。 `nosniff` 応答は意図的に推測を減らし、クライアントの修復を促すよりも正しいオリジン メタデータの重要性を高めることができます。
拡張子と MIME タイプ — プレーヤー、オペレーティング システム、ブラウザ ツールが実際に信頼するのはどれですか
プレーヤーとオペレーティング システムは、拡張子、MIME、バイト署名、および利用可能なコーデックをさまざまな順序で考慮する場合があります。すべての消費者に普遍的に勝てるレーベルはありません。
ToolAcre のフォールバック ファイル名は、Content-Disposition と最終パス セグメントが存在しない場合にのみ Content-Type を使用します。そこではWebMとMP4を認識します。それ以外の場合、総称名は `.bin` で終わります。アーカイブ ワークフローでは、両方のラベルを記録する必要があります。これは、不一致が一方をもう一方で黙って上書きする理由ではなく、診断の証拠であるためです。両方の値が一致しない場合は、その不一致が配信構成に関する有用な診断証拠となるため、両方の値をアーカイブします。
実用的な例: すべてをオクテットストリームとして提供するストレージバケットを修正 - ダウンロードと保存されたファイルの変更点
ストレージ バケットがすべてのオブジェクトをオクテット ストリームとして提供する場合は、ソースでメタデータを更新します。同じ承認されたファイルは、後のリクエストでより明確なプローブ行と正しく入力された Blob を生成できます。
ファイル名の優先順位が異なるため、既存のパスまたは Content-Disposition 名は変更されないままになる場合があります。 MIME ヘッダーを修正しても、バイトがトランスコードされたり、すでに他の場所で提供されている誤解を招く拡張子が修復されたりすることはありません。ストレージ コンソール フィールドを変更しても、すべての CDN キャッシュがそのフィールドを処理できるようになったことが証明されるわけではないため、メタデータの伝播後にリクエストを繰り返し、実際の応答を確認します。バケットのメタデータを変更した後は、コントロール パネルの保存確認を信頼するのではなく、キャッシュ伝播後の運用応答を検証します。
これでカバーされないもの — ファイル内のコンテナーとコーデック。ヘッダーでは保証できません。
Content-Type は、コンテナーの有効性、コーデック、期間、完全性、安全性、または再生可能性を保証できません。サーバーは偶然または意図的に嘘をつく可能性があり、約束の長さよりも前に転送が終了する可能性があります。
コンテナーとコーデックに関する質問には、信頼できる検査ソフトウェアを使用してください。ダウンローダーのジョブは、受信した本文を保存し、監視したサーバー ラベルを公開することで終了します。チェックサムと特殊なプローブを使用すると、正確なバイトについての信頼性を高めることができますが、このファイル保存インターフェイスではどちらも実装されません。チェックサムとコンテナ プローブは追加の事実を確立できますが、どちらの機能もこの焦点を絞ったダウンローダー インターフェイスには属しません。したがって、馴染みのあるラベルは、調査を終わらせずに導く必要があります。
要点: ラベルは重要 — ダイレクト メディア ダウンローダーが保存するものをダイレクト リンクの Content-Type によってどのように形成するか
形状の処理、警告、およびフォールバックの名前付けにラベルを付けるため、証拠ではありませんが重要です。ヘッダー、ファイル名、既知のソース、バイト数、再生を個別の証拠として比較します。
ダイレクト メディア ダウンローダーは、存在しないタイプを「サーバーによって示されていない」と報告し、Blob フォールバックを超えたタイプの作成を回避します。この制限により、ホストを修正できる人は設定ミスを認識できるようになります。ホスト所有者にとって、ダウンロード後に各訪問者にラベルの修復を要求するよりも、アップロード時にメタデータを修正する方がすべてのブラウザーとクライアントに利益をもたらします。その後、配信された応答を再確認してください。