HttpModule isn't extensible?

[Zach Baker]

What would be great is if the http module, in SerilogWeb.Classic.ApplicationLifecycleModule had some sort of hook to mix in more information from the http context when it was logging.

For instance, I have a scenario where I would really like to grab all the session data and dump it into the current log entry (enriched ideally) as the entire session.

Perhaps another take would be to have a hook that would allow me to set a particular context item, for the sake of logging, that had the data that I wanted, and then access to it with some clean enrichment, LogEventProperty, or something like that.

Really, having this module at all is helpful, thanks. Just thinking that some smoother way to sometimes add more session or context to a particular sink would be helpful.

[Thibaud Desodt]

Hi @zachrybaker ,
thanks for dropping by :)

Not really sure how much we want to change this library at this point, to be honest, given how ASP.NET Core is now "the new default".

I'm wondering if you would maybe be able to do this without changes to that library, though 🤔 .

Possibly, you could :

• add something under HttpContext.Items with a well-known key
• add an enricher to your logs that will enrich your generated log events with the data it finds inside HttpContext.Current.Items["the_key"]

[Zach Baker]

I think you have to look at it like this: while Microsoft supports framework, ideally so does Serilog, even if it's quite starchy :).

My scenario is supporting an old web app that talks to a mainframe. They are working on moving off the mainframe, so the app itself can't be changed right now to go to netcore. That will come two+ years down the road. The app is old, when I got involved I added Serilog. The app sends emails on errors (I know, don't do that, but I have to continue supporting their workflow, so I moved that to a custom sink). The app does filtered logging to one than one file sink as well, filtering calls to the mainframe (requests and responses) so that we can compare to calls to the migrated "mainframe" (running in framework OR netcore!). Another file (optionally) for soap calls, and a 3rd for app itself and any other issues.

Anyway, my workaround was that since I only need the session on errors, for that email sink, in the global event handler for application error, I go ahead and grab the session if available and shove it in to the exception data. That allows it to show up in the log event properties bag, which allows it to show up in the log entry.