Consider including a way to override the IHttpRequestIdentifierFeature implementation

[robbieknuth]

It would be easiest to use Kestrel's identifier, but we already have a well formatted request identifier, so changing to a new format isn't an option. Setting the trace identifier on the HttpContext isn't particularly helpful for logging because the request start scope was started before any middleware is called, so all logs use the traceidentifer set by Kestrel. We have to wrap our requests with a using and a logging scope to get the correlation we need. This doesn't always work, though, if there are errors before that part of the pipeline is reached.

I've not been able to figure out how to tell Kestrel to use a different implementation. It's possible that I'm missing something obvious but I've looked through the code for a while and tried a bunch of different things, no dice.

I would prefer not to fork and hack it. I think this feature would be generally useful, it can probably be done in a way that doesn't impacg perf, as the existing implementation is already pay-to-play.

[davidfowl]

This should be moved to aspnet/Hosting. All features are settable on the HttpContext you just need to be able to set it before the logging scope is created (which happens in hosting). You might consider making your own IHttpContextFactory.

    public class MyHttpContextFactory : IHttpContextFactory
    {
        private readonly HttpContextFactory _factory;
        public MyHttpContextFactory(IOptions<FormOptions> options)
        {
            // We're using the default implementation.
            _factory = new HttpContextFactory(options);
        }

        public HttpContext Create(IFeatureCollection featureCollection)
        {
            var context = _factory.Create(featureCollection);
            context.TraceIdentifier = "MyThing"; // Replace this with your own logic
            return context;
        }

        public void Dispose(HttpContext httpContext)
        {
            _factory.Dispose(httpContext);
        }
    }

Then wire it up in Startup.cs like so:

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddSingleton<IHttpContextFactory, MyHttpContextFactory>();
        }

[robbieknuth]

wellthatwaseasy.jpg

Thanks for the quick response, works exactly as advertised.