Optimize HttpDateParser.TryStringToDate (#34860)
authorStephen Toub <stoub@microsoft.com>
Sun, 12 Apr 2020 12:12:33 +0000 (08:12 -0400)
committerGitHub <noreply@github.com>
Sun, 12 Apr 2020 12:12:33 +0000 (08:12 -0400)
commit75efecb165fcb978eab98ee5971028ea6faf445e
treea16d478c4dd42d1ead6f1702d65573697ad03095
parentd185fbd2a7d04e9d0dac24f4260a42c312b9a529
Optimize HttpDateParser.TryStringToDate (#34860)

* Optimize HttpDateParser.TryStringToDate

When HttpResponseMessage headers are enumerated, even though SocketsHttpHandler adds headers with TryAddWithoutValidation, the enumeration ends up validating them (that's something to be discussed and follow-up on separately).  As part of that, it validates the Date header that's required of most responses. It does so using DateTimeOffset.TryParseExact, but using a long list of allowed formats as well as options that knock TryParseExact's processing off the fast path.  Since most responses are going to contain a date using RFC1123 format (aka "r"), we just try that first, in a way that will generally result in hitting the optimized "r" code path which is much faster.

* Address PR feedback
src/libraries/Common/src/System/Net/HttpDateParser.cs
src/libraries/Common/tests/Tests/System/Net/HttpDateParserTests.cs
src/libraries/System.Net.Http/src/System/Net/Http/Headers/ContentDispositionHeaderValue.cs
src/libraries/System.Net.Http/src/System/Net/Http/Headers/DateHeaderParser.cs
src/libraries/System.Net.Http/src/System/Net/Http/Headers/RangeConditionHeaderValue.cs
src/libraries/System.Net.Http/src/System/Net/Http/Headers/RetryConditionHeaderValue.cs
src/libraries/System.Net.Http/src/System/Net/Http/Headers/WarningHeaderValue.cs
src/libraries/System.Net.Requests/src/System/Net/HttpWebRequest.cs
src/libraries/System.Net.Requests/src/System/Net/HttpWebResponse.cs