Перейти на PRO

Какой жизненный цикл у middleware в ASP.NET Core?

Тип вопроса: ASP.NET Core Вероятность: 25% Категория: C# Разработчик

Ответ

Middleware в ASP.NET Core образует конвейер обработки HTTP-запроса и ответа. Каждый компонент middleware имеет четкий жизненный цикл в рамках одного запроса.

Основные этапы работы middleware:

  1. Входящая обработка (Before next): Middleware выполняет свою логику до передачи управления следующему компоненту в конвейере.
  2. Передача управления: Вызов next.Invoke() передает запрос следующему middleware. Если next не вызвать, цепочка обрывается (short-circuiting), что используется, например, в middleware для статических файлов или аутентификации.
  3. Исходящая обработка (After next): После того как следующий middleware и все последующие завершили работу, управление возвращается, и можно выполнить логику после обработки запроса (например, логирование, обработка исключений).

Порядок имеет значение: Middleware выполняются в том порядке, в котором они зарегистрированы в Program.cs (или Startup.Configure).

// Пример middleware, демонстрирующего жизненный цикл
app.Use(async (HttpContext context, RequestDelegate next) =>
{
    // 1. Действие ДО следующего middleware
    Console.WriteLine($"Before next: {context.Request.Path}");

    await next(context); // 2. Вызов следующего middleware в цепочке

    // 3. Действие ПОСЛЕ следующего middleware
    Console.WriteLine($"After next: {context.Response.StatusCode}");
});

// Следующий middleware в конвейере
app.UseRouting();
app.UseEndpoints(...);

Таким образом, жизненный цикл — это однонаправленный поток с возможностью "обернуть" обработку последующих компонентов.

Ответ 18+ 🔞

Слушай, давай разберём эту тему про middleware в ASP.NET Core, а то многие её так, на пальцах представляют, а потом удивляются, почему всё работает через жопу.

Представь себе конвейер, как на заводе, только вместо колбасы по нему едет HTTP-запрос. Каждый middleware — это такой работяга на линии, который может с запросом что-то сделать.

Жизненный цикл одного такого работяги — это три простых шага:

  1. Приёмка (До вызова next). Запрос приехал к нему на участок. Он может его осмотреть, понюхать, в лог записать, или сразу завернуть нахуй обратно, если что не так (это называется short-circuiting). Статические файлы или проверка аутентификации часто так и делают — не пустили и всё, дальше не пройдёшь.
  2. Передача по цеху (Сам вызов next). Если работяга решил, что запрос годный, он кричит: «Вали дальше!» — и вызывает next.Invoke(). Запрос едет к следующему middleware в очереди. А наш первый работяга пока ждёт, скрестив руки.
  3. Отгрузка (После вызова next). Запрос, пройдя через всю остальную линию (и, возможно, добравшись до самого контроллера), возвращается обратно тем же путём. И вот когда он снова проезжает мимо нашего первого работяги, тот может сделать финальные штрихи: посмотреть, какой статус-код в ответе, добавить какие-нибудь заголовки, или в лог написать, сколько времени вся эта эпопея заняла.

И вот тут главный подвох, который все проёбывают: порядок регистрации этих middleware в Program.cs — это святое. Это и есть порядок на конвейере. Если ты UseAuthentication() поставишь после UseRouting(), то маршрутизация сработает раньше, и твоя аутентификация может просто не получить нужных данных о запросе. Всё, пиздец, логика поехала.

// Типичный пример middleware, который всё про себя рассказывает
app.Use(async (HttpContext context, RequestDelegate next) =>
{
    // 1. Делаем что-то ДО передачи запроса дальше
    Console.WriteLine($"Запрос пришёл на путь: {context.Request.Path}. Время: {DateTime.Now}");

    await next(context); // 2. Кричим "Следующий!" и ждём

    // 3. Делаем что-то ПОСЛЕ того, как все остальные отработали
    Console.WriteLine($"Ответ ушёл со статусом: {context.Response.StatusCode}. Время: {DateTime.Now}");
});

// А вот следующие в цепочке ребята. Порядок — это всё.
app.UseRouting();
app.UseAuthentication(); // Важно поставить ДО авторизации, епта!
app.UseAuthorization();
app.MapControllers();

Короче, жизненный цикл — это такой челночный рейс: запрос пролетает через всех вперёд, потом, после обработки, так же пролетает назад, но уже в обратном порядке. И каждый middleware может его потрогать на любом из этих этапов. Главное — не накосячить с очередностью на сборочной линии.

© ХакСобесов, 2026
support@hacksobesov.com