You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Notice that right there it now calls response.StartAsync() -- that didn't use to happen; it just wrote the body.
The summary:
Once we call the localFunctionResult, the response is started and headers are marked as read-only. This is new in .NET Core 3: link to location in internal repo.
My analysis from an internal investigation (this is mostly a Teams transcript that I've cleaned up)
We end up with read-only headers when we try to set them in proxies -- this behavior is new in ASP.NET Core 3.0.
This PR changed it: dotnet/aspnetcore#7110. Specifically -- https://github.com/aspnet/AspNetCore/pull/7110/files#diff-6f529bca1b5cb1bf98dbd8b32d27969d.
Notice that right there it now calls response.StartAsync() -- that didn't use to happen; it just wrote the body.
The summary:
Once we call the
localFunctionResult
, the response is started and headers are marked as read-only. This is new in .NET Core 3: link to location in internal repo.so when we go to run the proxyResult -- the headers are locked and it throws: link to location in internal repo.
The text was updated successfully, but these errors were encountered: