0

このクラスを使用してRangeFilePathResult、MVCコントローラーからmp3ファイルを提供しています。

アクションは次のように定義されます。

[CacheFilter]
[OutputCache(CacheProfile = "Mp3Cache")]
public RangeFilePathResult Mp3Completed(string f)
{
    FileInfo info = new FileInfo(string.Format("C:\\test\\{0}.mp3", f));
    return new RangeFilePathResult("audio/mpeg", info.FullName, info.LastWriteTimeUtc, info.Length);
}

そして、キャッシュポリシーは次のとおりです。

<caching>
  <outputCacheSettings>
    <outputCacheProfiles>
      <add name="Mp3Cache" duration="3600" varyByParam="f" location="Any" />
    </outputCacheProfiles>
  </outputCacheSettings>
</caching>

なぜこれがそのまま正しく機能するのですか？varyByHeader範囲リクエストが出力キャッシングで機能することを保証するには、明示的にする必要があるようです。私が取り組んでいた問題は、iOS上のjPlayerがMP3ファイルの期間を表示できず、従来のFilePathResultを使用するとNaNをレンダリングすることでした。これは、この実装で機能します。

4

1 に答える 1

1

ここで最も重要なことは、範囲要求への応答が通常の200 OKではなく、206の部分的なコンテンツであるということです。

206パーシャルコンテンツの場合、いくつかの追加条件が満たされる必要があります。

  • リクエストにはRange、目的の範囲を示すヘッダーフィールドが含まれている必要がありIf-Range、リクエストを条件付きにするためのヘッダーフィールドが含まれている場合があります。
  • Content-Range応答には、この応答に含まれる範囲を示すヘッダーフィールド、または各部分の包含フィールドのいずれかをmultipart/byteranges Content-Type含める必要があります。Content-Range
  • 応答には、ETagおよび/またはContent-Location（ヘッダーが同じ要求への200応答で送信された場合）を含める必要があります
  • 応答には次のものが含まれている必要がありますDate

これで、HTTPプロトコルをサポートするすべてのキャッシュメカニズム（location="Any"これがブラウザ、プロキシサーバー、およびホスティングIISの場合）は、206パーシャルコンテンツが200 OKとは異なることを認識し、それに応じて処理する必要があります。以下に、 206パーシャルコンテンツレスポンスをキャッシュするための最も重要なルールを示します。

  • ETagまたはLast-Modifiedヘッダーが完全に一致しない場合、キャッシュは、206応答を以前にキャッシュされた他のコンテンツと組み合わせてはなりません。
  • RangeおよびヘッダーをサポートしContent-Rangeないキャッシュは、206の応答をキャッシュしてはなりません

varyByHeaderこれを要約すると、 HTTPプロトコルに従うすべてのキャッシュは、206パーシャルコンテンツの場合、ヘッダーRangeとContent-Rangeヘッダーがバリアントの一部であることを認識しているため、使用する必要はありません。

于 2012-09-12T20:22:07.960 に答える