- Today the async local reference to the HttpContext flows when the execution context is captured. When the http request has ended, the HttpContext property will return the reference to an invalid HttpContext instead of returning null. This change stores both the request id and the HttpContext and makes sure both match before returning anything valid.
- This is still racy but should catch more cases of people doing bad things.
- There will still be issue if people store the context in a local and use that reference instead of accessing it through the property getter but we can live with that.
- Set the TraceIdentifier to null in the default HttpContextFactory
- Added tests
- #549, #592
- move feature implementations to `Microsoft.AspNetCore.Http.Features` and `...Authentication.Features`
- move `DefaultHttpContext`, `HttpContextAccessor`, `HttpContextFactory`, `FormCollection` and
`HeaderDictionary` to `Microsoft.AspNetCore.Http`
- move `FormFile` to `Microsoft.AspNetCore.Http.Internal`
- that and `Microsoft.AspNetCore.Http.Authentication.Internal` are the remaining `.Internal` namespaces
nits:
- remove a couple of parameterless constructors
- add / fill subfolders to align with new namespaces
- remove all use of (unnecessary) "T:..." `<see cref=""/>` values
- #561
- new `SetCookieHeaderValue.AppendToStringBuilder()` method; avoids per-call `StringBuilder` allocation
- `ResponseCookies` uses `ObjectPool<StringBuilder>` that `ResponseCookiesFeature` provides
- `ResponseCookies` works fine if no `ObjectPoolProvider` is available
- `IHttpContextFactory` instance is a singleton instantiated from CI
- make `HttpContextFactory` `ObjectPoolProvider` and `ResponseCookiesFeature`-aware
- apply same pattern to sample `PooledHttpContextFactory`
- pool is not currently configurable; defaults are fine for response cookies
- if we need (policy) configuration, would add an `IOptions<HttpContextFactorySettings>`
nit: Add some doc comments