Store header values as byte[]

[benaadams]

Encode and store the header values as byte[] at the point they are added to the header dictionary { set }; encoding back to string if read by user code { get }; and using the byte[] when output to the socket (alternate IEnumerable interface?).

As strings are immutable this wouldn't break user code; to change the header the value would need to be set again. Response headers aren't read back that much by user code; oauth does it; but oauth is generally slow anyway.

This would mean the server header would only need to be encoded once for the lifetime and date only encoded once per second, rather than both on every response.

Additionally it would move the encoding time out of the socket write path which may improve throughput?

More of a suggestion than something backed up by hard metrics.

[Tratcher]

FYI: This probably conflicts with the coming change from string[] to StringValues :aspnet/HttpAbstractions#361

[benaadams]

Actually aspnet/HttpAbstractions#361 might make it easier as that puts the indirection in place?

[DamianEdwards]

Yep this is something that could be supported by StringValues.

[benaadams]

This has been more or less addressed

[benaadams]

Reopening this in light of #367 though would probably want some kind of HasBytes type of flag which could just be HasBytes => _valueBytes == null; then switch between using that or converting the string; e.g. keep it in the version it was set as.

Would likely want the byte[] version to be automatically converted and cached as string or string[] when used as such, but not auto conversion to byte[] as that would likely be memory inefficient.

For an example use, in benchmarks ContentType and Content-Length could be set to a static byte[]

/cc @davidfowl

[muratg]

@CesarBS could you check if this is done already? Feel free to ping @JunTaoLuo and @Tratcher

[Tratcher]

dotnet/extensions#68

[JunTaoLuo]

Will be addressed in the PR mentioned above.