Skip to content
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

[Announcement] HttpResponse body infrastructure changes #12635

Closed
Tratcher opened this issue Jul 26, 2019 · 9 comments
Closed

[Announcement] HttpResponse body infrastructure changes #12635

Tratcher opened this issue Jul 26, 2019 · 9 comments
Labels
area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions breaking-change This issue / pr will introduce a breaking change, when resolved / merged.
Milestone

Comments

@Tratcher
Copy link
Member

TLDR: The infrastructure backing HttpResponse bodies has changed. If you're using HttpResponse directly you should not need to make any code changes. Read further if you were wrapping or replacing HttpResponse.Body or accessing HttpContext.Features.

Version: 3.0.0-preview8

Background:
HttpContext, HttpRequest, HttpResponse are backed by an abstraction called Features. This allows functionality to be provided by different components in the pipeline without wrapping the entire HttpContext.

In 2.x there are three APIs associated with the response body: IHttpResponseFeature.Body, IHttpSendFileFeature.SendFileAsync, and IHttpBufferingFeature.DisableResponseBuffering, but the later two were rarely implemented or used.

Over the course of 3.0 several new response body APIs were added:
IHttpResponseBodyPipeFeature
IHttpResponseStartFeature.StartAsync
IHttpResponseCompleteFeature.CompleteAsync

Problem: With so many APIs it became too hard for middleware to properly intercept the response body. It was also hard for calling code to rely on those features being present on all servers.

Fix: Consolidate the response body APIs onto a single new feature interface IHttpResponseBodyFeature. HttpResponse has been updated accordingly, and each server has been updated to provide at least a minimal implementation for all of these APIs. We'll iterate to provide more fully featured implementations in each server but that won't require any more API changes.

Note if you replace HttpResponse.Body it will now replace the entire IHttpResponseBodyFeature with a wrapper around your given stream using StreamResponseBodyFeature to provide default implementations for all of the expected APIs. Setting back the original stream will undo this change.
https://github.com/aspnet/AspNetCore/blob/4aebd29abca80242f5ff9e89e07d4f1b28788a44/src/Http/Http/src/Internal/DefaultHttpResponse.cs#L67-L89

Breaking change #12328

Obsolete existing 2.x APIs
IHttpResponseFeature.Body
IHttpSendFileFeature
IHttpBufferingFeature

Deleted feature interfaces that were introduced earlier in 3.0.
IHttpResponseBodyPipeFeature
IHttpResponseStartFeature
IHttpResponseCompleteFeature

In a future major release we plan to refactor the request body features as well #12620.

@Joel-S-Black
Copy link

What nuget package is StreamResponseBodyFeature in? I downloaded Microsoft.AspNetCore.Http.Features, but I cannot resolve the reference.

@Tratcher
Copy link
Member Author

StreamResponseBodyFeature isn't in a nuget package, it's in the shared framework.

public class StreamResponseBodyFeature : IHttpResponseBodyFeature

https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.1&tabs=visual-studio#framework-reference

@Joel-S-Black
Copy link

I was not able to get a reference for StreamResponseBodyFeature to resolve by simply upgrading the framework version. I had to install Microsoft.Aspnetcore.Own nuget package, version 3.0.0. Oddly enough, the IHttpResponseBodyFeature resolved just fine with netstandard2.1 framework version.

@davidfowl
Copy link
Member

@Joel-S-Black
Copy link

Joel-S-Black commented May 22, 2020 via email

@davidfowl
Copy link
Member

So, my conclusion is that the class "StreamResponseBodyFeature" can only be used in a project targeting netcoreapp3 with "Microsoft.Aspnetcore.Owin", >= v3.0.0

You need to target netcoreapp3.x for sure but you also need to add a <FrameworkReference Include="Microsoft.AspNetCore.App" /> to the project. Refer to the doc I linked as it explains how to write class libraries that use ASP.NET Core.

ASP.NET Core 3.0 only works on .NET Core.

@Tratcher
Copy link
Member Author

The Microsoft.Aspnetcore.Owin package isn't required, but it would pull in the FrameworkReference for you.

@Joel-S-Black
Copy link

Joel-S-Black commented May 22, 2020

David, thanks for that link. Although I had read that page prior, I did not realize that FrameworkReferences were actually a thing (When I have previously read csprojs, I had thought that all things appearing to reference a name space was the same type of reference). Tratcher, thank you for your clarifying comment as well, it helped me to reconcile what I could see with what you were saying. I'm curious how I managed to get along so long not knowing that FrameworkReferences were a thing (since 2018)..

This would appear to be the documentation on FrameworkReferences: https://docs.microsoft.com/en-us/dotnet/core/packages .

In conclusion, the answer to my question about what nuget package to use make sure when using .net core 3 that you have '<"FrameworkReference Include="Microsoft.AspNetCore.App" />' in a project file ItemGroup tag.

peters added a commit to fintermobilityas/i18n.core that referenced this issue Sep 17, 2020
@jkotalik
Copy link
Contributor

Closing as this is already stable and has been in more than on release.

@ghost ghost locked as resolved and limited conversation to collaborators Dec 12, 2020
@amcasey amcasey added area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions and removed area-runtime labels Aug 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions breaking-change This issue / pr will introduce a breaking change, when resolved / merged.
Projects
None yet
Development

No branches or pull requests

6 participants