Sweet!

Hmm... If the headers aren't zeroed out after a request, and the application is responding with computed strings, couldn't this result in more computed string entering the gen1/gen2 heaps?

I mean, yes better for raw RPS, but worse for normal application loads?

result in more computed string entering the gen1/gen2 heaps?

Assuming the setters are clearing the references (either by setting a full StringValue set, or by setting the non-set components to null/empty) then it would only be rarely set headers that would be promoted, as the other ones would be cleared in the next request set - its just avoiding both a double clear (clear+set); and a clear of items that were never set in the first place.

Not sure about the implications pre-encoded change though; haven't looked too closely.

I'm not so sure that's a rare case - typically browsers will keep a couple connections open at a time, and you requests to arrive in small bursts with longish delays between. If reset doesn't zero the memory then all of the strings from the previous response will still be referenced by the header object during those long delays. So if you have a thousand browsers in the world with your web page open, and the GC kicks off, all of the strings from the most recent response for the thousand connections will move into the next generation.

Pre-encoded and string literals are no problem though - those should be treated like static readonly constants once they are created, and should move into the gen2 heap and stay there forever.

Solution for that might be to pool the header collections between connections so they aren't active in the keep-alive wait state?