Make concurrent reads on HttpHeaders thread-safe

[MihaZupan]

Fixes #61798
Lowers the impact of bugs like #66989 and #65379.

Adds no overhead if headers are both added & enumerated without validation.

Simpler to review when hiding whitespace changes.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #61798

Adds no overhead if headers are both added & enumerated without validation.

Author:	MihaZupan
Assignees:	MihaZupan
Labels:	area-System.Net.Http
Milestone:	7.0.0

[MihaZupan]

@dotnet/ncl PTAL

The change boils down to adding a lock when:

• The values in HeaderStoreItemInfo are being parsed (so its fields are being modified)
• The values are read from HeaderStoreItemInfo (non-validated reads / copying to a new header collection).

---

Since a value entry can transition from being a string to a HeaderStoreItemInfo, and we're not locking at those sites, it is expected that a single raw value may end up being parsed multiple times.
Such parsing is idempotent, so this is transparent to the user.

The code also has to be careful when reading the value of a given entry.
For example, the following logic would be problematic:

if (entries[i].Value is HeaderStoreItemInfo)
{
    // ...
}
else
{
    DoSomething((string)entries[i].Value); // Wrong! The value may now be HeaderStoreItemInfo
}

and it should instead be something like

object value = entries[i].Value;
if (value is HeaderStoreItemInfo)
{
    // ...
}
else
{
    DoSomething((string)value);
}

I've looked through our current code to make sure this is the case, but it's possible future changes may accidentally break this. I've added a test that should catch most such mistakes, but there may be cases that aren't covered.

[CarnaViire]

LGTM, but maybe someone else could also take a look 🙂

[CarnaViire]

Does this change fully address #61798 ? I see the issue mentioning invalid values too, but this change only adds locks?

[MihaZupan]

Does this change fully address #61798 ?

Yes. I split off the invalid values part into #67199, as that was a prerequisite for this change.

[juharris]

Will this change be in an upcoming version 6 update? If so, any idea when?

[MihaZupan]

It will be in preview 5 of .NET 7.

If you mean whether it will be backported to 6.0, there are currently no plans for that.