The middleware pipeline & useful logs

Understand the idea

Middleware forms a chain around each request. A component can inspect the request, call the next component, then inspect the result. It can also short-circuit the chain. Order changes behavior: authentication must establish a principal before authorization evaluates it.

Useful diagnostics explain an operation without exposing the user’s secrets. TaskBoard logs the method, path, status, and elapsed time. It adds a request identifier header so a browser observation can be connected to a server log.

Read the pipeline in order

Static files can return a response before MVC runs. Routing selects endpoint metadata. Authentication establishes identity. Authorization enforces endpoint requirements. The mapped controller or page finally handles the request.

Code after await next runs as control returns outward through the chain. An exception can interrupt that return path unless an outer handler catches it. Put exception handling early enough to cover the operations you intend to handle.

app.UseExceptionHandler("/Home/Error"); // outside Development
app.UseHttpsRedirection();
app.UseStaticFiles();
// Request diagnostics go here.
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();

Add timing and a response identifier

The stopwatch measures elapsed request work downstream from this component. OnStarting registers a callback before response headers are sent; this is the correct point to add a header even if later middleware starts the response.

The measurement is not a database-query duration or a browser rendering metric. Be precise about what a number represents before using it to diagnose performance.

app.Use(async (context, next) =>
{
    var clock = System.Diagnostics.Stopwatch.StartNew();
    context.Response.OnStarting(() =>
    {
        context.Response.Headers["X-Request-Id"] = context.TraceIdentifier;
        return Task.CompletedTask;
    });
    await next(context);
    app.Logger.LogInformation("{Method} {Path} returned {Status} in {Elapsed} ms",
        context.Request.Method, context.Request.Path,
        context.Response.StatusCode, clock.ElapsedMilliseconds);
});

Use structured fields rather than prose alone

Named placeholders become useful dimensions in a structured log store. Filtering on Status or Path is more reliable than parsing a long interpolated sentence. Keep parameter names consistent so related events can be searched together.

Do not log passwords, authorization headers, reset tokens, or complete form bodies. Query strings can contain tokens too. The example logs Request.Path, not the full URL, and avoids logging posted form values.

logger.LogInformation(
    "Updated task {TaskId} for request {RequestId}",
    task.Id, HttpContext.TraceIdentifier);
// Avoid logging credentials, cookies, or private task notes.

Inspect a real request

Request /health and inspect the response headers. Find X-Request-Id and compare the request with the application console. Then request a nonexistent route and observe the status.

For production, use a durable log sink, an appropriate retention policy, and distributed tracing when requests cross services. A console stream is convenient locally but can vanish with an ephemeral process. Add observability that answers real support questions rather than logging every variable.

curl -i http://localhost:5300/health
# Inspect HTTP status and X-Request-Id in the response headers.

When something doesn't work

“Headers are read-only, response has already started” means you tried to mutate headers too late. Use OnStarting before awaiting the next middleware.

A missing log may reflect log-level filtering rather than code that never ran. Inspect Logging configuration.

Sensitive values can appear in URLs as well as request bodies. Exclude token-bearing routes and avoid logging raw query strings.