-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add some missing APIs for HttpContext, HttpRequest and HttpResponse #91
Comments
After looking into these APIs, some are definitely doable while others are on the harder side and some others are probably not something we can really mimic. HttpContext We should probably do:
The following are very much tied to IIS. ASP.NET Core does not have a concept of handlers, the SkipAuthorization is tied to IIS authorization, and the SetSessionStateBehavior would only be used in IHttpModules I think
HttpRequest We should probably do:
These may be harder, but possible:
HttpResponse We should probably do:
These may be harder, but possible:
|
Triage: we consider SubStatusCode to be obsolete so we wouldn't enable support for it without a strong business justification. |
Let's do a first pass of the "straightforward" ones and then file separate issues for the more involved ones. |
These APIs are essentially the same, except that they had different memory characteristics. TransmitFile did not buffer, while WriteFile did. On ASP.NET Core, these will just delegate to IHttpResponseBodyFeature.SendFileAsync. NOTE: This implementation will cause async over sync to be done. We could potentially expose an async API for this on the ASP.NET Core side as a stepping stone if we want. Part of #91
These APIs are essentially the same, except that they had different memory characteristics. TransmitFile did not buffer, while WriteFile did. On ASP.NET Core, these will just delegate to IHttpResponseBodyFeature.SendFileAsync. NOTE: This implementation will call Task.GetAwaiter().GetResult(). We could potentially expose an async API for this on the ASP.NET Core side as a stepping stone if we want. Part of #91
These APIs are essentially the same, except that they had different memory characteristics. TransmitFile did not buffer, while WriteFile did. On ASP.NET Core, these will just delegate to IHttpResponseBodyFeature.SendFileAsync. NOTE: This implementation will call Task.GetAwaiter().GetResult(). We could potentially expose an async API for this on the ASP.NET Core side as a stepping stone if we want. Part of #91
These APIs are essentially the same, except that they had different memory characteristics. TransmitFile did not buffer, while WriteFile did. On ASP.NET Core, these will just delegate to IHttpResponseBodyFeature.SendFileAsync. NOTE: This implementation will call Task.GetAwaiter().GetResult(). We could potentially expose an async API for this on the ASP.NET Core side as a stepping stone if we want. Part of #91
These APIs are essentially the same, except that they had different memory characteristics. TransmitFile did not buffer, while WriteFile did. On ASP.NET Core, these will just delegate to IHttpResponseBodyFeature.SendFileAsync. NOTE: This implementation will call Task.GetAwaiter().GetResult(). We could potentially expose an async API for this on the ASP.NET Core side as a stepping stone if we want. Part of #91
This change adds a few APIs that were missing from HttpResponse. SubStatusCode is a placeholder for the value, but does not actually publish it anywhere. TransmitFile/WriteFile: These APIs are essentially the same, except that they had different memory characteristics. TransmitFile did not buffer, while WriteFile did. On ASP.NET Core, these will just delegate to IHttpResponseBodyFeature.SendFileAsync. NOTE: This implementation will call Task.GetAwaiter() which should be avoided. We could potentially expose an async API for this on the ASP.NET Core side as a stepping stone if we want. Part of #91
Issues will be tracked in linked issues, so closing this larger issue. |
Summary
Most primary APIs of HttpContext, HttpRequest and HttpResponse are provided, which is fantastic! And some missing APIs could be considered to be added to make this adapter more universal.
Motivation and goals
Some missing APIs are frequently used for .NET Framework and adding them to the adapter will make the migration smoother and more doable for large projects.
In scope
For HttpContext:
For HttpRequest:
HttpRequest.RequestContext
#151For HttpResponse:
Risks / unknowns
I can imagine not all of them make sense for ASP.NET Core, or fit .NET Core's design philosophy, or are easy to implement.
Examples
More APIs covered, more large projects could be benefited.
The text was updated successfully, but these errors were encountered: