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

@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.

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

Does this change fully address #61798 ?

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

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

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.