Provide an API to configure the TempDirectory used by ASP.NET Core

[pranavkm]

ASP.NET Core currently uses an environment variable to drive the temp directory, falling back Path.GetTempPath(). See https://github.com/aspnet/AspNetCore/blob/56e2080ef7741dea9a5c24a8e0639b0921be2d22/src/Http/Http/src/Internal/BufferingHelper.cs#L18-L39.

This path is currently in use by FileBufferingReadStream and as of #9015 change, by FileBufferingWriteStream.

This is one of the few parts of the stack that is only configurable via environment variable. We should instead follow the regular pattern of having an option type (that can be configured via configuration) and use those in when constructing these streams and everywhere else ASP.NET Core may need to write to the temp directory.

[pranavkm]

See #9015 (comment) for disussions. cc @Tratcher

[davidfowl]

Tricky as we don’t have a good way to flow this to the places that need this.

[Tratcher]

Yes we do. #9015 (comment)

[davidfowl]

That doesn't look like a solution. Doesn't that say pass an argument? Isn't this about defaults? What am I missing?

[Tratcher]

The options would be consumed by the thing creating the buffer streams such as EnableRewind or MVC's output formatters.
https://github.com/aspnet/AspNetCore/blob/425c196cba530b161b120a57af8f1dd513b96f67/src/Http/Http/src/Internal/BufferingHelper.cs#L41-L51
There was also a proposal to bundle that configuration and stream creation into a service/factory so the individual call sites didn't need to deal with it.

[analogrelay]

This seems reasonable but we don't have resources to address this in 3.0. The basic idea would be to resolve IOptions<HttpBufferingOptions> (where HttpBufferingOptions is a new type) in the EnableRewind method and use it to read this path instead of a global static.

This would be breaking since we'd be deleting (or even just not using) the existing static.

We could take a PR. It's not super complicated. But it will have to land in a major version because it's breaking.

[Tratcher]

Note we'd want to update MVC's XmlDataContractSerializerOutputFormatter, XmlSerializerOutputFormatter, and (Newtonsoft) JsonResultExecutor to read these options.

[cjaliaga]

In case of resolving IOptions<HttpBufferingOptions> in the EnableRewing method we could get the it from the request itself request.HttpContext.RequestServices.GetRequiredService<IOptions<HttpBufferingOptions>>().Value but, what about the EnableRewing for MultipartSection?
https://github.com/aspnet/AspNetCore/blob/425c196cba530b161b120a57af8f1dd513b96f67/src/Http/Http/src/Internal/BufferingHelper.cs#L58

For the streams (FileBufferingReadStream and FileBufferingWriteStream) should we keep the Func<string> tempFileDirectoryAccessor and pass one that reads from the directory specified in the options on the constructors such EnableRewing, MVC's XmlDataContractSerializerOutputFormatter, XmlSerializerOutputFormatter, (Newtonsoft) JsonResultExecutor...?

I'm commenting this because some ctors are now defaulting to the current function with the Environment variable:

_tempFileDirectoryAccessor = tempFileDirectoryAccessor ?? AspNetCoreTempDirectory.TempDirectoryFactory;

So what is the expected default for the temp directory used in streams when there's no func as param? I can think about:

• Setting one that will use Path.GetTempPath()
• Removing the possibility of not passing the func, ensuring that we always pass the func on stream's creation, coming from IOptions with Path.GetTempPath() as directory if user doesn't explicitly configure it
• Having a way from the streams to resolve IOptions, or a way to get a func from an static that does it. For me it doesn't sound right and not sure about its feasibility.