Closed orthoplex64 closed 4 years ago
@davidfowl related? https://github.com/aspnet/AspNetCore/issues/13991
Yes it’s the same bug
@davidfowl ping
What's the plan for 3.1? is this bug significantly important to include the fix?
Due to this subtle bug, it is risky to use the HeaderPropagation middleware at the moment. Is there any chance we can include the workaround https://github.com/aspnet/AspNetCore/pull/15435 in a patch release? The kestrel fix https://github.com/aspnet/AspNetCore/pull/14146 is still in progress and I doubt it will be backported to 3.1
If not possible to patch, should we document the bug somewhere (currently there is no documentation for this middleware) with some steps to take when using the middleware to avoid the bug? (e.g.: making sure this is not used as first async middleware in the pipeline)
/cc @rynowak
Agreed, we need to patch this.
@anurse how can this be moved forward? Should I create a PR with #15435 based on the 3.1 release branch?
@alefranz best bet is to send a PR to master
and open a separate PR later to backport it. We'll have to take the 3.1 backport PR for approval for servicing.
Although I'm not entirely clear on the current state since the linked PR was to master but closed.
If there's a change to be made in master
, it's best to start there and open a backport PR for approval. If the only change needed is in 3.1, we can go straight there and seek approval. If you're concerned about doing the work and then having it rejected, we can talk about the impact of the issue and risk of the change here and seek pre-approval.
Ok, caught up on the thread and I think I know what's up. @alefranz if you want to open a PR with the content for #15435 targetting release/3.1
, go for it. We can take a look and submit it for approval.
Thank you Andrew for looking into this.
I've raised a PR against release/3.1
#18300
This was fixed in https://github.com/dotnet/aspnetcore/pull/18300 which will be released in 3.1.3.
Describe the bug
When using
app.UseHeaderPropagation();
as the first middleware in the pipeline and sending many simultaneous requests, I've observed incorrect headers being propagated sometimes. When inserting any async middleware before header propagation (e.g.app.Use(async (context, next) => await next.Invoke());
), all propagated headers are correct.To Reproduce
Steps to reproduce the behavior (ASP.NET Core 3.0 by default):
dotnet run --project MangledHeaders
in the cloned repository.Use(async (context, next) => await next.Invoke())
in Startup.cs, re-run and see all the correct headers being returned Reproducible on ASP.NET Core 3.0 and 3.1. There is also a package reference to the ASP.NET Core 2.1/2.2 backport of the header propagation middleware, on which it is reproducible as well.Expected behavior
The correct headers (i.e. the ones included in the current request) should be propagated on requests sent by HTTP Clients to which the header-propagating message handler has been added.
Screenshots
Additional context
I don't think it matters here, but the bug reporting template says to include the output of
dotnet --info
, so here it is: