Double-check of FileInfo in SendFileFallback causes issues in templating

[nibblesnbits]

I've written a custom IFileProvider that does in-line replacements of file contents based on the incoming request. This worked back in .NET Core 2.2, but has since broken due to #12328.

The offending lines are below.

aspnetcore/src/Http/Http/src/SendFileFallback.cs

Lines 30 to 39 in 62e157b

	var fileInfo = new FileInfo(filePath);
	if (offset < 0 || offset > fileInfo.Length)
	{
	throw new ArgumentOutOfRangeException(nameof(offset), offset, string.Empty);
	}
	if (count.HasValue &&
	(count.Value < 0 || count.Value > fileInfo.Length - offset))
	{
	throw new ArgumentOutOfRangeException(nameof(count), count, string.Empty);
	}

Is there a new suggested approach if I need to send a modified or different file from a custom IFileProvider? Also, is it stricly necessary to have this check at all?

[Tratcher]

Are you using your custom IFileProvider with the StaticFile middleware? If the file length has been modified then your response has a mismatched Content-Length which can lead to protocol violations and failed responses.

Note the above code path is only hit if your IFileInfo preserves the original PhysicalPath property. If you're modifying the contents in the Stream then you'll want to remove the PhysicalPath property and update the length.

aspnetcore/src/Http/Http.Extensions/src/SendFileResponseExtensions.cs

Lines 115 to 138 in 62e157b

	private static async Task SendFileAsyncCore(HttpResponse response, IFileInfo file, long offset, long? count, CancellationToken cancellationToken)
	{
	if (string.IsNullOrEmpty(file.PhysicalPath))
	{
	CheckRange(offset, count, file.Length);
	using var fileContent = file.CreateReadStream();
	var useRequestAborted = !cancellationToken.CanBeCanceled;
	var localCancel = useRequestAborted ? response.HttpContext.RequestAborted : cancellationToken;
	try
	{
	localCancel.ThrowIfCancellationRequested();
	if (offset > 0)
	{
	fileContent.Seek(offset, SeekOrigin.Begin);
	}
	await StreamCopyOperation.CopyToAsync(fileContent, response.Body, count, StreamCopyBufferSize, localCancel);
	}
	catch (OperationCanceledException) when (useRequestAborted) { }
	}
	else
	{
	await response.SendFileAsync(file.PhysicalPath, offset, count, cancellationToken);

Have you considered doing this kind of inline processing in an MVC controller or custom middleware instead?

[nibblesnbits]

Yes, I am feeding that custom IFileProvider to the StaticFile middleware. I had no idea I could just not return a PhysicalPath! I'll update that and get back to you.

[nibblesnbits]

That totally works!

Would it make sense to put together something for the docs on a task like this? I can throw up a small example repo of my current code to ensure it's not a totally off-the-rails approach if need be.

[Tratcher]

Feel free, I doubt we have much coverage for custom file providers.

[nibblesnbits]

Will do! I'll link my repo here tonight and work on the docs soon.

[nibblesnbits]

Here's a quick-and-dirty demo: https://github.com/nibblesnbits/TemplateFileProviderDemo