[Kestrel] Support for custom decoder in headers

[analogrelay]

Follow up from #17399

In 5.0 we want to provide a hook to use a custom decoder for headers. A System.Text.Encoding.Encoder is probably not quite sufficient since the codec may want to see the header name in order to make decisions. A strawman API would be something like this:

string Decode(string headerName, ReadOnlySpan<byte> headerBytes);

[stephentoub]

A strawman API would be something like this

Would it make sense to be more like:

Encoding? GetEncodingForHeader(string headerName);

?

I'm thinking that would enable:

• more flexibility in the future, given the various APIs on Encoding
• the ability to cache an Encoding to use for a given header, which could in turn enable caching opportunities for a given input sequence
• potential devirtualization opportunities

Just a thought. Not sure if this has progressed since the original strawman.

[halter73]

Would it make sense to be more like:

Encoding? GetEncodingForHeader(string headerName);

I think that does make more sense. I assume a null return value tells the server or client to use its default behavior. Do you think an interface for this belongs in System.Net.Http @stephentoub?

[stephentoub]

Why would an interface be needed? It could just be a delegate?

(But, yes, is there's a good reason for this to be an interface, we should have one rather than two. I just prefer a delegate for a single operation as a) it's faster, b) it's easier for a caller to supply, and c) it doesn't require introducing a new type.)

[stephentoub]

I assume a null return value tells the server or client to use its default behavior.

That's my suggestion, as would not providing a delegate/interface at all.

[halter73]

Why would an interface be needed? It could just be a delegate?

It's not, and it could be. I was thinking about having custom decoders be registered via DI, but I understand this doesn't make sense for System.Net.