ASP.NET Core MVC のアクションメソッドを使って、ファイルをチャンク形式でエンコーディングしてブラウザにダウンロードする方法を書きます。（Core 版の MVC アプリの話です。.NET Framework 版は先の記事「MVC でチャンク形式でダウンロード」を見てください）
チャンク形式エンコーディングとは、 HTTP/1.1 で定義されている方式で、送信したいデータを任意のサイズのチャンク（塊）に分割し、各々のチャンクにサイズ情報を付与するエンコード方式です。（HTTP/2 はチャンク方式に対応しておらず、もっと効率的なデータストリーミングの仕組みを提供しているそうです）
メリットは、例えば、作成に時間がかかる大量のデータを動的に作成していて、作成中は全体のサイズが分からないが、部分的にでも作成でき次第送信を始められるというところにあるようです。（一旦全データをバッファして全体のサイズを調べ、Content-Length に設定するということをしなくても済みます）
概略方法を書きますと、(1) HttpResponse オブジェクトを取得、(2) それから Body プロパティを使って出力ストリームを取得、(3) コンテンツをチャンクに分割して WriteAsync メソッドでストリームに書き込む、(4) FlushAsync メソッドでクライアントに送信する、(5) 全チャンクを送信するまで (3) と (4) の操作を繰り返す・・・ということになります。
具体例はこの記事の下に載せたコードを見てください。test.pdf は 34,547 バイトの pdf ファイルで、下のコード例にあるアクションメソッドをブラウザから要求すると、その pdf ファイルのデータを 10,000 バイトずつチャンクに分けて送信するようになっています。
結果はこの記事の一番上の画像を見てください。Fiddler を使って要求・応答をキャプチャしたものです。応答ヘッダの赤線で示した部分を見るとチャンク形式エンコーディングになっていることが分かります。コンテンツの反転表示させた部分 32 37 31 30 に最初に送信されたチャンクのサイズが示されていることが分かります (文字コードは ASCII なので 32 37 31 30 は 2710 ⇒ 10 進数に直すと 10000)。
（注: Fiddler で応答コンテンツを見る際「Response body is encoded, Click to decode.」はクリックしないよう注意してください。クリックするとチャンクはまとめられ、さらに応答ヘッダには Content-Length が追加されて、チャンク形式ではなく普通にダウンロードされたように表示されます）
また、上のコードで送信データの最後を示す長さ 0 のチャンクも送信されています (Fiddler で最後のバイト列が 30 0D 0A 0D 0A となっているのを確認)。もちろん pdf ファイルも Content-Disposition に指定した名前で正しくダウンロードされます。
using Microsoft.AspNetCore.Mvc;
namespace MvcNet8App.Controllers
{
public class DownloadController : Controller
{
// Core では Server.MapPath が使えないことの対応
private readonly IWebHostEnvironment _hostingEnvironment;
public DownloadController(IWebHostEnvironment hostingEnvironment)
{
_hostingEnvironment = hostingEnvironment;
}
// アクションメソッドの戻り値は void または Task にできる
[HttpGet("/ChunkedDownload")]
[ResponseCache(Duration = 0,
Location = ResponseCacheLocation.None,
NoStore = true)]
public async Task ChunkedDownload(CancellationToken token)
{
// この例では、アプリケーションルート直下の Files という名前の
// フォルダの中の test.pdf というファイルをダウンロードする
string contentRootPath = _hostingEnvironment.ContentRootPath;
string physicalPath = contentRootPath + "\\" +
"Files\\" + "test.pdf";
// チャンクサイズは 10000 とした
int chunkSize = 10000;
Byte[] buffer = new Byte[chunkSize];
using (var stream = new FileStream(physicalPath, FileMode.Open))
{
long length = stream.Length;
// 応答ヘッダに Content-Type と Content-Disposition を含める
Response.ContentType = "application/pdf";
Response.Headers.Append("Content-Disposition",
"attachment;filename=test.pdf");
// MVC5 の Response.IsClientConnected は使えないので代わりに
// !token.IsCancellationRequested を使う
// アクションメソッドの引数に CancellationToken を追加してお
// けば、フレームワークが HttpContext.RequestAborted から取
// 得した CancellationToken を引数にバインドしてくれる
while (length > 0 && !token.IsCancellationRequested)
{
// チャンク形式でダウンロードされていることを確認するため
// 入れたコード。コメントアウトを外すとここで 3 秒待つ
//await Task.Delay(3000, CancellationToken.None);
int lengthRead = await stream.ReadAsync(
buffer.AsMemory(0, chunkSize),
token);
// MVC5 の Response.OutputStream は使えない
// 同期版のWrite メソッドは AllowSynchronousIO がデフォル
// トで false なので使えない
await Response.Body.WriteAsync(
buffer.AsMemory(0, lengthRead),
token);
// MVC5 の Response.Flush() は使えない
await Response.Body.FlushAsync(token);
length -= lengthRead;
}
}
}
}
}
注意点があるので以下に書いておきます。
注 1: IIS を使ってのインプロセスホスティングモデルでホストされる ASP.NET Core Web アプリは、クライアントによる要求の中断を検出してサーバー側の処理をキャンセルすることができます (詳しくは先の記事「要求の中断による処理のキャンセル (CORE)」を見てください)。
しかしながら、上のコードの最初の FlushAsync で応答ヘッダと最初のチャンクがブラウザに送信された時点で、ブラウザの X ボタンは表示されなくなり Esc キーは効かなくなって、それらの操作で処理は中断できなくなります。Windows 10 の Chrome 127.0.6533.89, Edge 127.0.2651.86, Firefox 128.0.3, Opera 112.0.5197.39 ですべて同じになることを確認しました。
ブラウザを閉じた場合、Edge 以外では処理は中断されますが、Edge では処理が続行されてダウンロードが完了してしまいます。理由はクライアントによる要求の中断情報を IIS に送れなくて、サーバー側で CancellationToken がキャンセル状態にならないためと思われますが、詳細は調べ切れておらず不明です。
注 2: 上の注 1 のクライアントによる要求の中断は、プロキシが入ると CancellationToken が IIS に届かなくなり、上のコードでは検出できなくなるので注意してください。（何故で検出できないのか悩んでいたら Fiddler を使っていたというのは内緒です（笑））
注 3: チャンクのバイト列を応答ストリームに書き込むのに同期メソッドの Write は使えません。使うと InvalidOperationException がスローされ、"Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead." というエラーになります。理由は AllowSynchronousIO が Keatrel を使う場合でも IIS を使う場合でもデフォルトで false に設定されているからだそうです。AllowSynchronousIO を true に設定するのではなく、上のコードのように WriteAsync メソッドを使うのが正解と思います。
注 4: ReadAsync および WriteAsync メソッドで、引数に Byte[], Int32, Int32, CancellationToken を取るオーバーロードを使うと、"より効率的なメモリベースのオーバーロードを呼び出すことをお勧めします" とのことでパフォーマンスルール CA1835 が出るので、それに従って Memory<Byte> / ReadOnlyMemory<Byte>, CancellationToken を引数に取るオーバーロードを使いました。