You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 18, 2018. It is now read-only.
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.
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.