Ask About HttpRequest.PhysicalPath

[Clounea]

Summary

Our repo uses HttpRequest.PhysicalPath which is not supported by ASP.NetCore and this adapters.
I want to ask if there is equivalent and if there is plan to add them to adapter.

Motivation and goals

We need migrate code (an API in Sharepoint) to ASP.NetCore and we find that the APIs are not supported by ASP.NetCore.

In scope

HttpRequest.PhysicalPath

From src code, it uses HostingEnvironment.MapPathInternal which is related to this issue: Ask About System.Web.Hosting.HostingEnvironment

Examples

 if (null != context.Request
                 && null != context.Request.PhysicalPath
                 && IsSuspiciousPhysicalPath(context.Request.PhysicalPath))
{
    Log("PhysicalPath is suspicious");
}

[twsouthwick]

This is a tricky one as there is really no concept of physical paths in ASP.NET Core. It could probably be added to IHttpRequestPathFeature and surfaced that way.

[twsouthwick]

This may be able to be implemented by:

internal interface IHttpRequestPathFeature
{
+  string? PhysicalPath { get; }
}

With a default implementation that would look at IWebHostEnvironment.WebRootFileProvider and see if it is a physical path.

OR the default implementation could just be null (looks like you check for null) since they don't really point to a physical path anymore

@CZEMacLeod - I know you've looked into mapping the various IFileProvider stuff into this kind of thing, so checking if you have thoughts.

[CZEMacLeod]

@twsouthwick Interesting. Most of the stuff I was looking at was related to Path, PathInfo and FilePath - although as you say, most requests (other than those that would be consumed by the StaticFile middleware) won't have an actual physical file.
In Asp.Net terms, it runs as if you were using the runAllManagedModulesForAllRequests flag, so you don't need an actual file to trigger mapping into dotnet.
It also relates somewhat to the work you and I both had a look at to do with IHttpHandler.
I like the idea of checking for a physical file using the FileProvider. I have some code for wrapping the existing FileProvider as a VirtualPathProvider so it can register as the default MapPathVirtualPathProvider equivalent, then wrapping the VPP chain as a FileProvider for the StaticFiles middleware. This would work well with that to allow VirtualFiles to also be handled correctly.
I feel like the default provider is perhaps a null provider, but you could configure it to use the more advanced, but perhaps slower, one with IFileProvider, perhaps taken as an input to a WithPhysicalPathProvider(this IServiceCollection services, IFileProvider provider) type extension method to replace the default one registered?
It might be worthwhile noting that one thing that is less clear in Asp.Net is the separation of client content, from the application resources. This means that it is difficult to know whether to use WebRootFileProvider or ContentRootFileProvider at times. I haven't had time to check if there is much work already done on how things like App_Data and other normally blocked paths are handled in the Core side?

[twsouthwick]

I'm putting a change up to surface the API. If we enable #332 by exposing the internal features, then someone could build on top of it to enable some semantics that make sense here