dotnet / systemweb-adapters

MIT License
338 stars 61 forks source link

Enable HttpRequest APIs dependent on VirtualPathUtility #149

Open twsouthwick opened 2 years ago

twsouthwick commented 2 years ago

Summary

A number of APIs on HttpRequest rely on the VirtualPathUtility. Once that's available (https://github.com/dotnet/systemweb-adapters/issues/83), these APIs may be built on it.

In scope

CZEMacLeod commented 2 years ago

HttpResponse.ApplyAppPathModifier is used for cookieless session handling - so I don't think is in scope.

FilePath and PathInfo, other that the trivial implementation which would match MVC5 and WebApi2, don't quite seem to have an equivalent in AspNetCore. They only come into effect when a filetype in mapped to a handler in IIS, and that effectively becomes the 'script' that is running, and anything after the path to the file, is treated as PathInfo. This seems mainly to fit webpages use where the 'script' is the .aspx file. I'm not sure there is an easy way this fits in AspNetCore terms, as everything is just done with endpoint routing.

I have done the basics for

If you want it - https://github.com/CZEMacLeod/systemweb-adapters/commit/16a9820c97cbdcce7a3c012968e1b9645e119b62

CZEMacLeod commented 2 years ago

@twsouthwick If you add IHttpHandler to the mix, it makes sense to map FilePath and PathInfo as they relate to the handler. I did a quick version of IHttpHandler here https://github.com/CZEMacLeod/systemweb-adapters/tree/czemacleod/ihttphandler

This includes

Also for Core:

Also fixes for HttpRequest.AppRelativeCurrentExecutionFilePath and HttpServer.MapPath due to the difference between Path and FilePath when PathInfo is not empty.