ASP.NET Core Middleware

A także Rick Anderson i Steve Smith

Oprogramowanie pośredniczące to oprogramowanie, które jest składane w potok aplikacji w celu obsługi żądań i odpowiedzi. Każdy składnik:

  • Określa, czy przekazywać żądanie do następnego składnika w potoku.
  • Może wykonywać pracę przed następnym składnikiem w potoku i po nim.

Delegaty żądań są używane do kompilowania potoku żądań. Delegaci żądania obsługują każde żądanie HTTP.

Delegaty żądań są konfigurowane przy użyciu Run Map metod , i Use rozszerzeń. Delegat pojedynczego żądania może być określony w wierszu jako metoda anonimowa (nazywana oprogramowaniem pośredniczącem w wierszu) lub może być zdefiniowany w klasie wielokrotnego użytku. Te klasy wielokrotnego użytku i metody anonimowe w wierszu są oprogramowaniem pośredniczącem, nazywanymi również składnikami oprogramowania pośredniczącego. Każdy składnik oprogramowania pośredniczącego w potoku żądania jest odpowiedzialny za wywołania następnego składnika w potoku lub jego krótkich obwodów. Gdy oprogramowanie pośredniczące ma krótkie obwody, jest nazywane końcowym oprogramowaniem pośredniczącem, ponieważ uniemożliwia dalszemu procesowi pośredniczącemu przetwarzanie żądania.

Migrowanie programów obsługi i modułów HTTP do ASP.NET Core pośredniczącegowyjaśnia różnicę między potokami żądań w programach ASP.NET Core i ASP.NET 4.x oraz udostępnia dodatkowe przykłady oprogramowania pośredniczącego.

Tworzenie potoku oprogramowania pośredniczącego za pomocą WebApplication

Potok ASP.NET Core żądania składa się z sekwencji delegatów żądań, wywoływanych jeden po drugim. Na poniższym diagramie przedstawiono koncepcję. Wątek wykonywania podąża za czarnymi strzałkami.

Wzorzec przetwarzania żądań przedstawiający żądanie docierające, przetwarzanie za pośrednictwem trzech oprogramowania pośredniczącego i odpowiedź opuszczania aplikacji. Każde oprogramowanie pośredniczące uruchamia swoją logikę i ujmuje żądanie do następnego oprogramowania pośredniczącego przy następnej instrukcji (). Po przetworzeniu żądania przez trzecie oprogramowanie pośredniczące żądanie przechodzi z powrotem przez dwa poprzednie oprogramowanie pośredniczące w odwrotnej kolejności w celu dodatkowego przetwarzania po ich instrukcjach next() przed opuszczeniem aplikacji jako odpowiedzi dla klienta.

Każdy delegat może wykonywać operacje przed następnym obiektem delegowanym i po nim. Delegaty obsługi wyjątków powinny być wywoływane na wczesnym etapie potoku, aby można było wychwycić wyjątki występujące w późniejszych etapach potoku.

Najprostsza możliwa aplikacja ASP.NET Core skonfigurować pojedynczego delegata żądania, który obsługuje wszystkie żądania. Ten przypadek nie obejmuje rzeczywistego potoku żądania. Zamiast tego pojedyncza funkcja anonimowa jest wywoływana w odpowiedzi na każde żądanie HTTP.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello world!");
});

app.Run();

Łańcuch wielu delegatów żądań razem z Use . Parametr next reprezentuje następnego delegata w potoku. Potok można zawęźć, nie wywołując next parametru . Zazwyczaj można wykonywać akcje zarówno przed, jak i po delegacie, jak pokazano w next poniższym przykładzie:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Use(async (context, next) =>
{
    // Do work that doesn't write to the Response.
    await next.Invoke();
    // Do logging or other work that doesn't write to the Response.
});

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello from 2nd delegate.");
});

app.Run();

Jeśli delegat nie przekaże żądania do następnego delegata, jest on nazywany krótkim obwodem potoku żądania. Krótkie obwody są często pożądane, ponieważ unikają niepotrzebnej pracy. Na przykład oprogramowanie pośredniczące plików statycznych może działać jako oprogramowanie pośredniczące terminalu, przetwarzając żądanie dla pliku statycznego i krótki czas w pozostałej części potoku. Oprogramowanie pośredniczące dodane do potoku przed oprogramowaniem pośredniczącem, które kończy dalsze przetwarzanie, nadal przetwarza kod po ich next.Invoke instrukcjach. Zobacz jednak następujące ostrzeżenie dotyczące próby zapisu w odpowiedzi, która została już wysłana.

Ostrzeżenie

Nie należy wywołać next.Invoke wywołania po wysłaniu odpowiedzi do klienta. Zmiany wprowadzone HttpResponse w elementach po zakończeniu odpowiedzi zwywają wyjątek. Na przykład ustawienie nagłówków i kodu stanu zgłasza wyjątek. Zapisywanie w treści odpowiedzi po wywołaniu next funkcji :

  • Może spowodować naruszenie protokołu. Na przykład pisanie więcej niż określono Content-Length .
  • Może uszkodzić format treści. Na przykład zapisywanie stopki HTML do pliku CSS.

HasStarted jest przydatną wskazówką wskazującą, czy nagłówki zostały wysłane, czy treść została napisana.

Run Delegaci nie otrzymują next parametru. Pierwszy delegat Run jest zawsze terminalem i kończy potok. Run jest konwencją. Niektóre składniki oprogramowania pośredniczącego mogą Run[Middleware] ujawniać metody uruchamiane na końcu potoku:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Use(async (context, next) =>
{
    // Do work that doesn't write to the Response.
    await next.Invoke();
    // Do logging or other work that doesn't write to the Response.
});

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello from 2nd delegate.");
});

app.Run();

Jeśli chcesz zobaczyć komentarze do kodu przetłumaczone na języki inne niż angielski, daj nam znać w tym problemie z dyskusją w serwisie GitHub.

W poprzednim przykładzie delegat zapisuje w odpowiedzi, Run "Hello from 2nd delegate." a następnie kończy potok. Jeśli po delegacie zostanie dodany inny delegat Use lub , nie zostanie on Run Run wywołany.

Preferuj aplikację. Używanie przeciążenia wymagającego przekazywania kontekstu do następnego

Aplikacja, która nie przydziela. Użyj metody rozszerzenia:

  • Wymaga przekazywania kontekstu do next .
  • Zapisuje dwa wewnętrzne alokacje na żądanie, które są wymagane podczas korzystania z innego przeciążenia.

Aby uzyskać więcej informacji, zobacz ten GitHub problem.

Kolejność oprogramowania pośredniczącego

Na poniższym diagramie przedstawiono pełny potok przetwarzania żądań dla ASP.NET Core MVC Razor i Pages. Możesz zobaczyć, jak w typowej aplikacji są uporządkowane istniejące oprogramowanie pośredniczące i gdzie są dodawane niestandardowe oprogramowanie pośredniczące. Masz pełną kontrolę nad tym, jak zmieniać kolejność istniejących oprogramowania pośredniczącego lub wprowadzać nowe niestandardowe oprogramowanie pośredniczące zgodnie z potrzebami scenariuszy.

ASP.NET Core potok oprogramowania pośredniczącego

Oprogramowanie pośredniczące Punktu końcowego na poprzednim diagramie wykonuje potok filtru dla odpowiedniego typu aplikacji — MVC lub Razor Pages.

Oprogramowanie pośredniczące routingu na powyższym diagramie przedstawiono poniżej: Pliki statyczne. Jest to kolejność implementowana przez szablony projektów przez jawne wywoływanie aplikacji. UseRouting. Jeśli nie wywołasz wywołania , oprogramowanie pośredniczące Routing jest domyślnie uruchamiane na app.UseRouting początku potoku. Aby uzyskać więcej informacji, zobacz Routing.

ASP.NET Core potoku filtru

Kolejność dodawana składników oprogramowania pośredniczącego w pliku Program.cs definiuje kolejność wywoływania składników oprogramowania pośredniczącego w żądaniach oraz odwrotną kolejność odpowiedzi. Kolejność ma kluczowe znaczenie dla bezpieczeństwa, wydajności i funkcjonalności.

Następujący kod wyróżniony w programie Program.cs dodaje składniki oprogramowania pośredniczącego związane z zabezpieczeniami w typowej zalecanej kolejności:

using IndividualAccountsExample.Data;
using Microsoft.AspNetCore.Identity;
using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(connectionString));
builder.Services.AddDatabaseDeveloperPageExceptionFilter();

builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
    .AddEntityFrameworkStores<ApplicationDbContext>();
builder.Services.AddRazorPages();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseMigrationsEndPoint();
}
else
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();
// app.UseCookiePolicy();

app.UseRouting();
// app.UseRequestLocalization();
// app.UseCors();

app.UseAuthentication();
app.UseAuthorization();
// app.UseSession();
// app.UseResponseCompression();
// app.UseResponseCaching();

app.MapRazorPages();
app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

app.Run();

Powyższy kod ma następujące działanie:

  • Oprogramowanie pośredniczące, które nie jest dodawane podczas tworzenia nowej aplikacji internetowej z kontami poszczególnych użytkowników, jest oznaczane jako komentarz.
  • Nie każde oprogramowanie pośredniczące pojawia się w tej dokładnej kolejności, ale wiele z nich robi. Na przykład:
    • UseCors, UseAuthentication i muszą być wyświetlane w UseAuthorization podanej kolejności.
    • UseCors obecnie musi pojawić się przed UseResponseCaching . To wymaganie wyjaśniono w GitHub dotnet/aspnetcore #23218.
    • UseRequestLocalization musi pojawić się przed dowolnym oprogramowaniem pośredniczącem, które może sprawdzać kulturę żądania (na przykład app.UseMvcWithDefaultRoute() ).

W niektórych scenariuszach oprogramowanie pośredniczące ma różne kolejność. Na przykład buforowanie i kolejność kompresji jest specyficzna dla scenariusza i istnieje wiele prawidłowych kolejności. Na przykład:

app.UseResponseCaching();
app.UseResponseCompression();

W poprzednim kodzie użycie procesora CPU można zmniejszyć przez buforowanie skompresowanej odpowiedzi, ale może to spowodować buforowanie wielu reprezentacji zasobu przy użyciu różnych algorytmów kompresji, takich jak Gzip lub Brotli.

Następujące uporządkowanie łączy pliki statyczne w celu umożliwienia buforowania skompresowanych plików statycznych:

app.UseResponseCaching();
app.UseResponseCompression();
app.UseStaticFiles();

Następujący kod Program.cs dodaje składniki oprogramowania pośredniczącego dla typowych scenariuszy aplikacji:

  1. Obsługa wyjątków/błędów
    • Gdy aplikacja jest uruchamiana w środowisku dewelopera:
      • Oprogramowanie pośredniczące strony wyjątku dewelopera UseDeveloperExceptionPage () zgłasza błędy środowiska uruchomieniowego aplikacji.
      • Oprogramowanie pośredniczące strony błędu bazy danych ( UseDatabaseErrorPage ) zgłasza błędy czasu wykonywania bazy danych.
    • Gdy aplikacja jest uruchamiana w środowisku produkcyjnym:
      • Oprogramowanie pośredniczące programu obsługi wyjątków ( UseExceptionHandler ) przechwytuje wyjątki zgłaszane w następujących oprogramowaniach pośredniczące.
      • Oprogramowanie pośredniczące HTTP Strict Transport Security Protocol (HSTS) ( UseHsts ) dodaje Strict-Transport-Security nagłówek .
  2. Oprogramowanie pośredniczące przekierowania HTTPS ( UseHttpsRedirection ) przekierowuje żądania HTTP do protokołu HTTPS.
  3. Oprogramowanie pośredniczące plików statycznych () zwraca pliki statyczne i UseStaticFiles krótkie obwody dalszego przetwarzania żądań.
  4. Cookie Oprogramowanie pośredniczące zasad ( ) jest zgodne z przepisami UseCookiePolicy UE Ogólne rozporządzenie o ochronie danych (RODO).
  5. Oprogramowanie pośredniczące routingu ( UseRouting ) do kierowania żądań.
  6. Oprogramowanie pośredniczące uwierzytelniania ( ) próbuje uwierzytelnić użytkownika przed uzyskaniem dostępu UseAuthentication do zabezpieczonych zasobów.
  7. Oprogramowanie pośredniczące autoryzacji ( UseAuthorization ) autoryzuje użytkownika do uzyskiwania dostępu do zabezpieczonych zasobów.
  8. Oprogramowanie pośredniczące sesji ( UseSession ) ustanawia i utrzymuje stan sesji. Jeśli aplikacja używa stanu sesji, wywołaj oprogramowanie pośredniczące sesji po oprogramowanie Cookie pośredniczące zasad i przed oprogramowaniem pośredniczącem MVC.
  9. Oprogramowanie pośredniczące routingu punktu końcowego ( UseEndpoints MapRazorPages z ) do dodawania punktów końcowych Razor stron do potoku żądań.
if (env.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
    app.UseDatabaseErrorPage();
}
else
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseCookiePolicy();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.UseSession();
app.MapRazorPages();

W poprzednim przykładowym kodzie każda metoda rozszerzenia oprogramowania pośredniczącego jest udostępniane za WebApplicationBuilder pośrednictwem przestrzeni Microsoft.AspNetCore.Builder nazw .

UseExceptionHandler to pierwszy składnik oprogramowania pośredniczącego dodany do potoku. W związku z tym oprogramowanie pośredniczące obsługi wyjątków przechwytuje wszelkie wyjątki występujące w późniejszych wywołaniach.

Oprogramowanie pośredniczące plików statycznych jest wywoływane na wczesnym etapie potoku, dzięki czemu może obsługiwać żądania i krótkie obwody bez konieczności przechodzinia przez pozostałe składniki. Oprogramowanie pośredniczące plików statycznych nie sprawdza autoryzacji. Wszystkie pliki obsługiwane przez oprogramowanie pośredniczące plików statycznych, w tym pliki w folderze wwwroot, są publicznie dostępne. Aby uzyskać informacje na temat podejścia do zabezpieczania plików statycznych, zobacz Pliki statyczne w ASP.NET Core .

Jeśli żądanie nie jest obsługiwane przez oprogramowanie pośredniczące plików statycznych, jest przekazywane do oprogramowania pośredniczącego uwierzytelniania ( ), które UseAuthentication przeprowadza uwierzytelnianie. Uwierzytelnianie nie ma krótkiego obwodu dla nieuwierzytanych żądań. Mimo że oprogramowanie pośredniczące uwierzytelniania uwierzytelnia żądania, autoryzacja (i odrzucanie) występuje tylko wtedy, gdy MVC wybierze określoną stronę lub Razor kontroler MVC i akcję.

W poniższym przykładzie pokazano kolejność oprogramowania pośredniczącego, w której żądania dotyczące plików statycznych są obsługiwane przez oprogramowanie pośredniczące plików statycznych przed oprogramowaniem pośredniczącem kompresji odpowiedzi. Pliki statyczne nie są kompresowane za pomocą tej kolejności oprogramowania pośredniczącego. Odpowiedzi Razor strony mogą być kompresowane.

// Static files aren't compressed by Static File Middleware.
app.UseStaticFiles();

app.UseRouting();

app.UseResponseCompression();

app.MapRazorPages();

Aby uzyskać informacje o aplikacjach jednostronicowych, zobacz przewodniki dotyczące React i Angular szablonów projektów.

Kolejność oprogramowania pośredniczącego nagłówków dalej

Oprogramowanie pośredniczące Nagłówki dalej powinno być uruchamiane przed innym oprogramowaniem pośredniczącem. To uporządkowanie zapewnia, że oprogramowanie pośredniczące, które korzysta z informacji o nagłówkach przesyłanych dalej, może używać wartości nagłówka do przetwarzania. Aby uruchomić oprogramowanie pośredniczące Przekazane nagłówki po zakończeniu diagnostyki i obsługi błędów oprogramowania pośredniczącego, zobacz Kolejność oprogramowania pośredniczącego Przekazane nagłówki.

Rozgałęzienie potoku oprogramowania pośredniczącego

Map Rozszerzenia są używane jako konwencja rozgałęzienia potoku. Map odgałęzienie potoku żądania na podstawie dopasowania danej ścieżki żądania. Jeśli ścieżka żądania rozpoczyna się od podanej ścieżki, gałąź jest wykonywana.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Map("/map1", HandleMapTest1);

app.Map("/map2", HandleMapTest2);

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello from non-Map delegate. <p>");
});

app.Run();

static void HandleMapTest1(IApplicationBuilder app)
{
    app.Run(async context =>
    {
        await context.Response.WriteAsync("Map Test 1");
    });
}

static void HandleMapTest2(IApplicationBuilder app)
{
    app.Run(async context =>
    {
        await context.Response.WriteAsync("Map Test 2");
    });
}

W poniższej tabeli przedstawiono żądania i odpowiedzi z http://localhost:1234 używania poprzedniego kodu.

Żądanie Reakcja
localhost:1234 Witaj od delegata spoza mapy.
localhost:1234/map1 Test mapy 1
localhost:1234/map2 Test mapy 2
localhost:1234/map3 Witaj od delegata spoza mapy.

Gdy jest używany, dopasowane segmenty ścieżki są usuwane z i Map HttpRequest.Path dołączane do HttpRequest.PathBase dla każdego żądania.

Map Obsługuje zagnieżdżanie, na przykład:

app.Map("/level1", level1App => {
    level1App.Map("/level2a", level2AApp => {
        // "/level1/level2a" processing
    });
    level1App.Map("/level2b", level2BApp => {
        // "/level1/level2b" processing
    });
});

Map Może również odpowiadać wielu segmentom jednocześnie:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Map("/map1/seg1", HandleMultiSeg);

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello from non-Map delegate. <p>");
});

app.Run();

static void HandleMultiSeg(IApplicationBuilder app)
{
    app.Run(async context =>
    {
        await context.Response.WriteAsync("Map Test 1");
    });
}

MapWhen rozgałęzienie potoku żądania na podstawie wyniku danego predykatu. Dowolny predykat typu może Func<HttpContext, bool> służyć do mapowania żądań na nową gałąź potoku. W poniższym przykładzie predykat jest używany do wykrywania obecności zmiennej ciągu zapytania branch :

public class Startup
{
    private static void HandleBranch(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            var branchVer = context.Request.Query["branch"];
            await context.Response.WriteAsync($"Branch used = {branchVer}");
        });
    }

    public void Configure(IApplicationBuilder app)
    {
        app.MapWhen(context => context.Request.Query.ContainsKey("branch"),
                               HandleBranch);

        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello from non-Map delegate. <p>");
        });
    }
}

W poniższej tabeli przedstawiono żądania i odpowiedzi z http://localhost:1234 poprzedniego kodu:

Żądanie Reakcja
localhost:1234 Witaj od delegata spoza mapy.
localhost:1234/?branch=main Używana gałąź = main

UseWhen program rozgałęzienia potoku żądań na podstawie wyniku danego predykatu. W przeciwieństwie do systemu ta gałąź jest ponownie dołączana do głównego potoku, jeśli nie ma krótkiego obwodu ani nie MapWhen zawiera oprogramowania pośredniczącego terminalu:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.UseWhen(context => context.Request.Query.ContainsKey("branch"),
    appBuilder => HandleBranchAndRejoin(appBuilder));

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello from non-Map delegate. <p>");
});

app.Run();

void HandleBranchAndRejoin(IApplicationBuilder app)
{
    var logger = app.ApplicationServices.GetRequiredService<ILogger<Program>>(); 

    app.Use(async (context, next) =>
    {
        var branchVer = context.Request.Query["branch"];
        logger.LogInformation("Branch used = {branchVer}", branchVer);

        // Do work that doesn't write to the Response.
        await next();
        // Do other work that doesn't write to the Response.
    });
}

W poprzednim przykładzie odpowiedź "Hello from main pipeline" (Witaj z głównego potoku). jest zapisywany dla wszystkich żądań. Jeśli żądanie zawiera zmienną ciągu zapytania , jej wartość jest rejestrowana przed ponownego dołączenia do głównego branch potoku.

Wbudowane oprogramowanie pośredniczące

ASP.NET Core jest dostarczany z następującymi składnikami oprogramowania pośredniczącego. Kolumna Kolejność zawiera uwagi dotyczące umieszczania oprogramowania pośredniczącego w potoku przetwarzania żądań i warunków, w których oprogramowanie pośredniczące może zakończyć przetwarzanie żądania. Gdy oprogramowanie pośredniczące zwęczy potok przetwarzania żądań i uniemożliwia dalsze podrzędne oprogramowanie pośredniczące przetwarzanie żądania, jest nazywane końcowym oprogramowaniem pośredniczącem. Aby uzyskać więcej informacji na temat krótkich obwodów, zobacz sekcję Tworzenie potoku oprogramowania pośredniczącego za pomocą klasy IApplicationBuilder.

Oprogramowanie pośredniczące Opis Zamówienie
Authentication Zapewnia obsługę uwierzytelniania. Przed HttpContext.User jest wymagany. Terminal dla wywołań zwrotnych protokołu OAuth.
Autoryzacja Zapewnia obsługę autoryzacji. Bezpośrednio po uwierzytelnianiu oprogramowania pośredniczącego.
Cookie Zasad Śledzi zgodę użytkowników na przechowywanie danych osobowych i wymusza minimalne standardy dla cookie pól, takich jak secure i SameSite . Przed oprogramowaniem pośredniczącem, które wydaje cookie s. Przykłady: uwierzytelnianie, sesja, MVC (TempData).
CORS Konfiguruje udostępnianie zasobów między źródłami. Przed składnikami, które używają cors. UseCorsObecnie z powodu tej usterki należy UseResponseCaching przejść wcześniej.
DeveloperExceptionPage Generuje stronę z informacjami o błędzie, które są przeznaczone tylko do użytku w środowisku dewelopera. Przed składnikami, które generują błędy. Szablony projektu automatycznie rejestruje to oprogramowanie pośredniczące jako pierwsze oprogramowanie pośredniczące w potoku, gdy środowisko to Development.
Diagnostyka Kilka oddzielnych oprogramowania pośredniczącego, które zapewniają stronę wyjątku dewelopera, obsługę wyjątków, strony kodowe stanu i domyślną stronę internetową dla nowych aplikacji. Przed składnikami, które generują błędy. Terminal obsługujący wyjątki lub obsługujący domyślną stronę internetową dla nowych aplikacji.
Przekazane nagłówki Przekazuje nagłówki proxy do bieżącego żądania. Przed składnikami, które zużywają zaktualizowane pola. Przykłady: schemat, host, adres IP klienta, metoda.
Kontrola kondycji Sprawdza kondycję aplikacji ASP.NET Core i jej zależności, takie jak sprawdzanie dostępności bazy danych. Terminal, jeśli żądanie pasuje do punktu końcowego kontroli kondycji.
Propagacja nagłówka Propaguje nagłówki HTTP z żądania przychodzącego do wychodzących żądań klienta HTTP.
Rejestrowanie HTTP Rejestruje żądania HTTP i odpowiedzi HTTP. Na początku potoku oprogramowania pośredniczącego.
Przesłonięcie metody HTTP Umożliwia zastąpienie metody przychodzącym żądaniem POST. Przed składnikami, które zużywają zaktualizowaną metodę.
Przekierowywanie HTTPS Przekieruj wszystkie żądania HTTP do protokołu HTTPS. Przed składnikami, które zużywają adres URL.
Http Strict Transport Security (HSTS) Oprogramowanie pośredniczące rozszerzenia zabezpieczeń, które dodaje specjalny nagłówek odpowiedzi. Przed wysłaniem odpowiedzi i po składnikach, które modyfikują żądania. Przykłady: Przekazane nagłówki, Ponowne zapisywanie adresów URL.
MVC Przetwarza żądania za pomocą wzorca Razor MVC/stron. Terminal, jeśli żądanie pasuje do trasy.
OWIN Interop with OWIN-based apps, servers, and middleware (Interop with OWIN-based apps, servers, and middleware). Terminal, jeśli oprogramowanie pośredniczące OWIN w pełni przetwarza żądanie.
Odpowiedź Buforowanie Zapewnia obsługę buforowania odpowiedzi. Przed składnikami, które wymagają buforowania. UseCORSmusi znajdować się przed . UseResponseCaching
Kompresja odpowiedzi Zapewnia obsługę kompresowania odpowiedzi. Przed składnikami, które wymagają kompresji.
Lokalizacja żądania Zapewnia obsługę lokalizacji. Przed lokalizacji poufnych składników. Musi występować po oprogramowanie pośredniczące routingu w przypadku korzystania z programu RouteDataRequestCultureProvider .
Routing punktów końcowych Definiuje i ogranicza trasy żądań. Terminal do dopasowywania tras.
SPA Obsługuje wszystkie żądania od tego momentu w łańcuchu oprogramowania pośredniczącego, zwracając domyślną stronę aplikacji jednostronicowej (SPA) Pod koniec łańcucha pierwszeństwo ma inne oprogramowanie pośredniczące do obsługi plików statycznych, akcji MVC itp.
Sesja Zapewnia obsługę zarządzania sesjami użytkowników. Przed składnikami, które wymagają sesji.
Pliki statyczne Zapewnia obsługę obsługi plików statycznych i przeglądania katalogów. Terminal, jeśli żądanie pasuje do pliku.
Ponowne zapisywanie adresów URL Zapewnia obsługę ponownego ritowania adresów URL i przekierowywania żądań. Przed składnikami, które zużywają adres URL.
Rejestrowanie W3C Generuje dzienniki dostępu do serwera w formacie rozszerzonego pliku dziennika W3C. Na początku potoku oprogramowania pośredniczącego.
Protokoły WebSocket Włącza protokół WebSockets. Przed składnikami wymaganymi do akceptowania żądań WebSocket.

Dodatkowe zasoby

A którzy: Rick Anderson i Steve Smith

Oprogramowanie pośredniczące to oprogramowanie, które jest składane w potok aplikacji w celu obsługi żądań i odpowiedzi. Każdy składnik:

  • Określa, czy przekazywać żądanie do następnego składnika w potoku.
  • Może wykonywać pracę przed następnym składnikiem w potoku i po nim.

Delegaty żądań są używane do kompilowania potoku żądań. Delegaci żądania obsługują każde żądanie HTTP.

Delegaty żądań są konfigurowane Run przy użyciu metod , i Map Use rozszerzeń. Delegat pojedynczego żądania można określić w wierszu jako metodę anonimową (nazywaną oprogramowaniem pośredniczącem w wierszu) lub w klasie wielokrotnego użytku. Te klasy wielokrotnego użytku i metody anonimowe są oprogramowaniem pośredniczącem, nazywanym również składnikami oprogramowania pośredniczącego. Każdy składnik oprogramowania pośredniczącego w potoku żądania jest odpowiedzialny za wywołania następnego składnika w potoku lub jego krótkiego obwodu. Gdy oprogramowanie pośredniczące ma krótkie obwody, jest nazywane końcowym oprogramowaniem pośredniczącem, ponieważ uniemożliwia dalszemu procesowi pośredniczącemu przetwarzanie żądania.

Migrowanie programów obsługi i modułów HTTP do ASP.NET Core pośredniczącegowyjaśnia różnicę między potokami żądań w programach ASP.NET Core i ASP.NET 4.x oraz udostępnia dodatkowe przykłady oprogramowania pośredniczącego.

Tworzenie potoku oprogramowania pośredniczącego przy użyciu klasy IApplicationBuilder

Potok ASP.NET Core żądań składa się z sekwencji delegatów żądań, wywoływanych jeden po drugim. Na poniższym diagramie przedstawiono koncepcję. Wątek wykonywania następuje po czarnych strzałkach.

Wzorzec przetwarzania żądań przedstawiający żądanie docierające, przetwarzanie za pośrednictwem trzech oprogramowania pośredniczącego i odpowiedź opuszczania aplikacji. Każde oprogramowanie pośredniczące uruchamia swoją logikę i ujmuje żądanie do następnego oprogramowania pośredniczącego przy następnej instrukcji (). Po przetworzeniu żądania przez trzecie oprogramowanie pośredniczące żądanie przechodzi z powrotem przez dwa poprzednie oprogramowanie pośredniczące w odwrotnej kolejności w celu dodatkowego przetwarzania po instrukcjach next() przed opuszczeniem aplikacji jako odpowiedzi dla klienta.

Każdy delegat może wykonywać operacje przed następnym obiektem delegowanym i po nim. Delegaty obsługi wyjątków powinny być wywoływane na wczesnym etapie potoku, aby można było wychwycić wyjątki występujące na późniejszych etapach potoku.

Najprostszy z możliwych ASP.NET Core konfiguruje pojedynczego delegata żądania, który obsługuje wszystkie żądania. Ten przypadek nie zawiera rzeczywistego potoku żądania. Zamiast tego pojedyncza funkcja anonimowa jest wywoływana w odpowiedzi na każde żądanie HTTP.

public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello, World!");
        });
    }
}

Za pomocą łańcucha wielu delegatów żądań należy przy użyciu łańcucha Use . Parametr next reprezentuje następnego delegata w potoku. Potok można zerć, nie wywołując następnego parametru. Zazwyczaj można wykonywać akcje zarówno przed, jak i po następnym delegacie, jak pokazano w poniższym przykładzie:

public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        app.Use(async (context, next) =>
        {
            // Do work that doesn't write to the Response.
            await next.Invoke();
            // Do logging or other work that doesn't write to the Response.
        });

        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello from 2nd delegate.");
        });
    }
}

Gdy delegat nie przekazuje żądania do następnego delegata, jest on nazywany krótkim obwodem potoku żądania. Skróty są często pożądane, ponieważ unikają niepotrzebnej pracy. Na przykład oprogramowanie pośredniczące plików statycznych może działać jako oprogramowanie pośredniczące terminalu, przetwarzając żądanie dla pliku statycznego i zwęając pozostałą część potoku. Oprogramowanie pośredniczące dodane do potoku przed oprogramowaniem pośredniczącem, które kończy dalsze przetwarzanie, nadal przetwarza kod po ich next.Invoke instrukcjach. Zobacz jednak poniższe ostrzeżenie dotyczące próby zapisu w odpowiedzi, która została już wysłana.

Ostrzeżenie

Nie należy wywołać next.Invoke po wysłaniu odpowiedzi do klienta. Zmiany w HttpResponse elementach po rozpoczętiu odpowiedzi zrzucą wyjątek. Na przykład ustawienie nagłówków i kodu stanu zgłasza wyjątek. Zapisywanie w treści odpowiedzi po wywołaniu funkcji next :

  • Może spowodować naruszenie protokołu. Na przykład pisanie więcej niż określono Content-Length .
  • Może spowodować uszkodzenie formatu treści. Na przykład zapisywanie stopki HTML do pliku CSS.

HasStarted jest przydatną wskazówką wskazującą, czy nagłówki zostały wysłane, czy treść została napisana.

Run Delegaci nie otrzymują next parametru. Pierwszy delegat Run jest zawsze terminalem i kończy potok. Run jest konwencją. Niektóre składniki oprogramowania pośredniczącego mogą Run[Middleware] uwidaczniać metody uruchamiane na końcu potoku:

public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        app.Use(async (context, next) =>
        {
            // Do work that doesn't write to the Response.
            await next.Invoke();
            // Do logging or other work that doesn't write to the Response.
        });

        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello from 2nd delegate.");
        });
    }
}

Jeśli chcesz zobaczyć komentarze do kodu przetłumaczone na języki inne niż angielski, daj nam znać w tym problemie z dyskusją w serwisie GitHub.

W poprzednim przykładzie delegat zapisuje w odpowiedzi, a następnie Run "Hello from 2nd delegate." kończy potok. Jeśli po delegacie zostanie dodany inny delegat Use lub , nie zostanie on Run Run wywołany.

Kolejność oprogramowania pośredniczącego

Na poniższym diagramie przedstawiono pełny potok przetwarzania żądań dla aplikacji ASP.NET Core MVC Razor i Pages. Możesz zobaczyć, jak w typowej aplikacji są uporządkowane istniejące oprogramowanie pośredniczące i gdzie są dodawane niestandardowe oprogramowanie pośredniczące. Masz pełną kontrolę nad tym, jak zmieniać kolejność istniejących oprogramowania pośredniczącego lub wprowadzać nowe niestandardowe oprogramowanie pośredniczące zgodnie z potrzebami dla scenariuszy.

ASP.NET Core potok oprogramowania pośredniczącego

Oprogramowanie pośredniczące Endpoint na powyższym diagramie wykonuje potok filtru dla odpowiedniego typu aplikacji — MVC lub Razor Pages.

ASP.NET Core potoku filtru

Kolejność dodawana składników oprogramowania pośredniczącego w metodzie definiuje kolejność wywoływania składników oprogramowania pośredniczącego w żądaniach oraz odwrotną kolejność Startup.Configure odpowiedzi. Kolejność ma kluczowe znaczenie dla bezpieczeństwa, wydajności i funkcjonalności.

Następująca metoda dodaje składniki oprogramowania pośredniczącego związane z zabezpieczeniami Startup.Configure w typowej zalecanej kolejności:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
        app.UseDatabaseErrorPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();
    // app.UseCookiePolicy();

    app.UseRouting();
    // app.UseRequestLocalization();
    // app.UseCors();

    app.UseAuthentication();
    app.UseAuthorization();
    // app.UseSession();
    // app.UseResponseCompression();
    // app.UseResponseCaching();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
        endpoints.MapControllerRoute(
            name: "default",
            pattern: "{controller=Home}/{action=Index}/{id?}");
    });
}

Powyższy kod ma następujące działanie:

  • Oprogramowanie pośredniczące, które nie jest dodawane podczas tworzenia nowej aplikacji internetowej z kontami poszczególnych użytkowników, jest oznaczane jako komentarz.
  • Nie każde oprogramowanie pośredniczące pojawia się w tej dokładnej kolejności, ale wiele z nich robi. Na przykład:
    • UseCors, UseAuthentication i muszą występować w UseAuthorization podanej kolejności.
    • UseCorsObecnie z powodu tej usterki musi UseResponseCaching pojawić się przed .
    • UseRequestLocalization musi pojawić się przed dowolnym oprogramowaniem pośredniczącem, które może sprawdzać kulturę żądania (na przykład app.UseMvcWithDefaultRoute() ).

W niektórych scenariuszach oprogramowanie pośredniczące ma różne kolejność. Na przykład buforowanie i kolejność kompresji jest specyficzna dla scenariusza i istnieje wiele prawidłowych kolejności. Na przykład:

app.UseResponseCaching();
app.UseResponseCompression();

Powyższy kod umożliwia zapisanie procesora CPU przez buforowanie skompresowanej odpowiedzi, ale może to spowodować buforowanie wielu reprezentacji zasobu przy użyciu różnych algorytmów kompresji, takich jak Gzip lub Brotli.

Następująca kolejność łączy pliki statyczne w celu umożliwienia buforowania skompresowanych plików statycznych:

app.UseResponseCaching();
app.UseResponseCompression();
app.UseStaticFiles();

Następująca Startup.Configure metoda dodaje składniki oprogramowania pośredniczącego dla typowych scenariuszy aplikacji:

  1. Obsługa wyjątków/błędów
    • Gdy aplikacja jest uruchamiana w środowisku projektowym:
      • Oprogramowanie pośredniczące strony wyjątku UseDeveloperExceptionPage dewelopera () zgłasza błędy środowiska uruchomieniowego aplikacji.
      • Oprogramowanie pośredniczące strony błędu bazy danych zgłasza błędy czasu wykonywania bazy danych.
    • Gdy aplikacja jest uruchamiana w środowisku produkcyjnym:
      • Oprogramowanie pośredniczące obsługi wyjątków ( UseExceptionHandler ) przechwytuje wyjątki zgłaszane w następujących oprogramowaniach pośredniczącego.
      • Oprogramowanie pośredniczące HTTP Strict Transport Security Protocol (HSTS) ( UseHsts ) dodaje Strict-Transport-Security nagłówek .
  2. Oprogramowanie pośredniczące przekierowania HTTPS ( UseHttpsRedirection ) przekierowuje żądania HTTP do protokołu HTTPS.
  3. Oprogramowanie pośredniczące plików statycznych () zwraca pliki statyczne i UseStaticFiles krótkie obwody dalszego przetwarzania żądań.
  4. Cookie Oprogramowanie pośredniczące zasad () jest zgodne z przepisami UseCookiePolicy UE Ogólne rozporządzenie o ochronie danych (RODO).
  5. Oprogramowanie pośredniczące routingu ( UseRouting ) do kierowania żądań.
  6. Oprogramowanie pośredniczące uwierzytelniania () próbuje uwierzytelnić użytkownika, UseAuthentication zanim będzie mógł uzyskać dostęp do zabezpieczonych zasobów.
  7. Oprogramowanie pośredniczące autoryzacji ( UseAuthorization ) autoryzuje użytkownika do uzyskiwania dostępu do zabezpieczonych zasobów.
  8. Oprogramowanie pośredniczące sesji ( UseSession ) ustanawia i utrzymuje stan sesji. Jeśli aplikacja używa stanu sesji, wywołaj oprogramowanie pośredniczące sesji po Cookie oprogramowania pośredniczącego zasad i przed oprogramowaniem pośredniczącem MVC.
  9. Oprogramowanie pośredniczące routingu punktu końcowego ( UseEndpoints MapRazorPages z ) do dodawania punktów końcowych Razor stron do potoku żądań.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
        app.UseDatabaseErrorPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();
    app.UseCookiePolicy();
    app.UseRouting();
    app.UseAuthentication();
    app.UseAuthorization();
    app.UseSession();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

W poprzednim przykładowym kodzie każda metoda rozszerzenia oprogramowania pośredniczącego jest udostępniane za IApplicationBuilder pośrednictwem przestrzeni Microsoft.AspNetCore.Builder nazw .

UseExceptionHandler to pierwszy składnik oprogramowania pośredniczącego dodany do potoku. W związku z tym oprogramowanie pośredniczące obsługi wyjątków przechwytuje wszelkie wyjątki występujące w późniejszych wywołaniach.

Oprogramowanie pośredniczące plików statycznych jest wywoływane na wczesnym etapie potoku, dzięki czemu może obsługiwać żądania i krótkie obwody bez konieczności przechodzinia przez pozostałe składniki. Oprogramowanie pośredniczące plików statycznych nie sprawdza autoryzacji. Wszystkie pliki obsługiwane przez oprogramowanie pośredniczące plików statycznych, w tym pliki w folderze wwwroot, są publicznie dostępne. Aby uzyskać informacje na temat podejścia do zabezpieczania plików statycznych, zobacz Pliki statyczne w ASP.NET Core .

Jeśli żądanie nie jest obsługiwane przez oprogramowanie pośredniczące pliku statycznego, jest ono przekazywane do oprogramowania pośredniczącego uwierzytelniania ( ), które UseAuthentication przeprowadza uwierzytelnianie. Uwierzytelnianie nie ma krótkiego obwodu dla nieuwierzytanych żądań. Mimo że oprogramowanie pośredniczące uwierzytelniania uwierzytelnia żądania, autoryzacja (i odrzucanie) występuje tylko wtedy, gdy MVC wybierze określoną stronę lub Razor kontroler MVC i akcję.

W poniższym przykładzie pokazano kolejność oprogramowania pośredniczącego, w której żądania dotyczące plików statycznych są obsługiwane przez oprogramowanie pośredniczące plików statycznych przed oprogramowaniem pośredniczącem kompresji odpowiedzi. Pliki statyczne nie są kompresowane za pomocą tej kolejności oprogramowania pośredniczącego. Odpowiedzi Razor strony mogą być kompresowane.

public void Configure(IApplicationBuilder app)
{
    // Static files aren't compressed by Static File Middleware.
    app.UseStaticFiles();

    app.UseRouting();

    app.UseResponseCompression();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

W przypadku aplikacji jednostronicowych (SPA) oprogramowanie pośredniczące SPA zazwyczaj występuje UseSpaStaticFiles jako ostatnie w potoku oprogramowania pośredniczącego. Oprogramowanie pośredniczące SPA jest ostatni:

  • Aby umożliwić wszystkim innym oprogramowaniem pośredniczącem odpowiadanie najpierw na pasujące żądania.
  • Aby umożliwić uruchamianie aplikacji spA z routingiem po stronie klienta dla wszystkich tras, które są nierozpoznane przez aplikację serwera.

Aby uzyskać więcej informacji na temat niestandardowych aplikacji, zobacz przewodniki dotyczące React i Angular szablonów projektów.

Kolejność oprogramowania pośredniczącego nagłówków przekazywania

Oprogramowanie pośredniczące Nagłówki dalej powinno być uruchamiane przed innym oprogramowaniem pośredniczącem. To uporządkowanie zapewnia, że oprogramowanie pośredniczące, które korzysta z informacji o nagłówkach przesyłanych dalej, może używać wartości nagłówka do przetwarzania. Aby uruchomić oprogramowanie pośredniczące Przekazane nagłówki po zakończeniu diagnostyki i obsługi błędów oprogramowania pośredniczącego, zobacz Kolejność oprogramowania pośredniczącego Przekazane nagłówki.

Rozgałęzienie potoku oprogramowania pośredniczącego

Map Rozszerzenia są używane jako konwencja rozgałęzienia potoku. Map odgałęzienie potoku żądania na podstawie dopasowania danej ścieżki żądania. Jeśli ścieżka żądania rozpoczyna się od podanej ścieżki, gałąź jest wykonywana.

public class Startup
{
    private static void HandleMapTest1(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            await context.Response.WriteAsync("Map Test 1");
        });
    }

    private static void HandleMapTest2(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            await context.Response.WriteAsync("Map Test 2");
        });
    }

    public void Configure(IApplicationBuilder app)
    {
        app.Map("/map1", HandleMapTest1);

        app.Map("/map2", HandleMapTest2);

        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello from non-Map delegate. <p>");
        });
    }
}

W poniższej tabeli przedstawiono żądania i odpowiedzi z http://localhost:1234 poprzedniego kodu.

Żądanie Reakcja
localhost:1234 Witaj od delegata spoza mapy.
localhost:1234/map1 Test mapy 1
localhost:1234/map2 Test mapy 2
localhost:1234/map3 Witaj od delegata spoza mapy.

Gdy jest używany, dopasowane segmenty ścieżki są usuwane z i Map HttpRequest.Path dołączane do HttpRequest.PathBase dla każdego żądania.

Map obsługuje zagnieżdżanie, na przykład:

app.Map("/level1", level1App => {
    level1App.Map("/level2a", level2AApp => {
        // "/level1/level2a" processing
    });
    level1App.Map("/level2b", level2BApp => {
        // "/level1/level2b" processing
    });
});

Map Może również odpowiadać wielu segmentom jednocześnie:

public class Startup
{
    private static void HandleMultiSeg(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            await context.Response.WriteAsync("Map multiple segments.");
        });
    }

    public void Configure(IApplicationBuilder app)
    {
        app.Map("/map1/seg1", HandleMultiSeg);

        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello from non-Map delegate.");
        });
    }
}

MapWhen rozgałęzienie potoku żądania na podstawie wyniku danego predykatu. Dowolny predykat typu może Func<HttpContext, bool> służyć do mapowania żądań na nową gałąź potoku. W poniższym przykładzie predykat jest używany do wykrywania obecności zmiennej ciągu zapytania branch :

public class Startup
{
    private static void HandleBranch(IApplicationBuilder app)
    {
        app.Run(async context =>
        {
            var branchVer = context.Request.Query["branch"];
            await context.Response.WriteAsync($"Branch used = {branchVer}");
        });
    }

    public void Configure(IApplicationBuilder app)
    {
        app.MapWhen(context => context.Request.Query.ContainsKey("branch"),
                               HandleBranch);

        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello from non-Map delegate. <p>");
        });
    }
}

W poniższej tabeli przedstawiono żądania i odpowiedzi z http://localhost:1234 poprzedniego kodu:

Żądanie Reakcja
localhost:1234 Witaj od delegata spoza mapy.
localhost:1234/?branch=main Używana gałąź = main

UseWhen ponadto rozgałęzienia potoku żądania na podstawie wyniku danego predykatu. W przeciwieństwie do systemu ta gałąź jest ponownie dołączana do głównego potoku, jeśli nie ma krótkiego obwodu ani nie MapWhen zawiera oprogramowania pośredniczącego terminalu:

public class Startup
{
    private void HandleBranchAndRejoin(IApplicationBuilder app, ILogger<Startup> logger)
    {
        app.Use(async (context, next) =>
        {
            var branchVer = context.Request.Query["branch"];
            logger.LogInformation("Branch used = {branchVer}", branchVer);

            // Do work that doesn't write to the Response.
            await next();
            // Do other work that doesn't write to the Response.
        });
    }

    public void Configure(IApplicationBuilder app, ILogger<Startup> logger)
    {
        app.UseWhen(context => context.Request.Query.ContainsKey("branch"),
                               appBuilder => HandleBranchAndRejoin(appBuilder, logger));

        app.Run(async context =>
        {
            await context.Response.WriteAsync("Hello from main pipeline.");
        });
    }
}

W poprzednim przykładzie odpowiedź "Hello from main pipeline" (Witaj z głównego potoku). jest zapisywany dla wszystkich żądań. Jeśli żądanie zawiera zmienną ciągu zapytania , jej wartość jest rejestrowana przed ponownego dołączenia do branch głównego potoku.

Wbudowane oprogramowanie pośredniczące

ASP.NET Core jest dostarczany z następującymi składnikami oprogramowania pośredniczącego. Kolumna Kolejność zawiera uwagi dotyczące umieszczania oprogramowania pośredniczącego w potoku przetwarzania żądań i warunków, w których oprogramowanie pośredniczące może zakończyć przetwarzanie żądania. Gdy oprogramowanie pośredniczące zwęczy potok przetwarzania żądań i uniemożliwia dalsze podrzędne oprogramowanie pośredniczące przetwarzanie żądania, jest nazywane końcowym oprogramowaniem pośredniczącem. Aby uzyskać więcej informacji na temat krótkich obwodów, zobacz sekcję Tworzenie potoku oprogramowania pośredniczącego za pomocą klasy IApplicationBuilder.

Oprogramowanie pośredniczące Opis Zamówienie
Authentication Zapewnia obsługę uwierzytelniania. Przed HttpContext.User jest wymagany. Terminal dla wywołań zwrotnych protokołu OAuth.
Autoryzacja Zapewnia obsługę autoryzacji. Bezpośrednio po uwierzytelnianiu oprogramowania pośredniczącego.
Cookie Zasad Śledzi zgodę użytkowników na przechowywanie danych osobowych i wymusza minimalne standardy dla cookie pól, takich jak secure i SameSite . Przed oprogramowaniem pośredniczącem, które wydaje cookie s. Przykłady: uwierzytelnianie, sesja, MVC (TempData).
CORS Konfiguruje udostępnianie zasobów między źródłami. Przed składnikami, które używają cors. UseCors obecnie musi przejść przed z UseResponseCaching powodu tej usterki.
Diagnostyka Kilka oddzielnych oprogramowania pośredniczącego, które zapewniają stronę wyjątków dla deweloperów, obsługę wyjątków, strony kodowe stanu i domyślną stronę internetową dla nowych aplikacji. Przed składnikami, które generują błędy. Terminal do obsługi wyjątków lub obsługi domyślnej strony internetowej dla nowych aplikacji.
Przekazane nagłówki Przekazuje nagłówki proxy do bieżącego żądania. Przed składnikami, które zużywają zaktualizowane pola. Przykłady: schemat, host, adres IP klienta, metoda.
Kontrola kondycji Sprawdza kondycję aplikacji ASP.NET Core i jej zależności, takie jak sprawdzanie dostępności bazy danych. Terminal, jeśli żądanie pasuje do punktu końcowego kontroli kondycji.
Propagacja nagłówka Propaguje nagłówki HTTP z żądania przychodzącego do wychodzących żądań klienta HTTP.
Przesłonięcie metody HTTP Umożliwia przesłanianie metody przez przychodzące żądanie POST. Przed składnikami, które zużywają zaktualizowaną metodę.
Przekierowywanie HTTPS Przekieruj wszystkie żądania HTTP do protokołu HTTPS. Przed składnikami, które zużywają adres URL.
Http Strict Transport Security (HSTS) Oprogramowanie pośredniczące rozszerzenia zabezpieczeń, które dodaje specjalny nagłówek odpowiedzi. Przed wysłaniem odpowiedzi i po składnikach, które modyfikują żądania. Przykłady: przekazane nagłówki, ponowne zapisywanie adresów URL.
MVC Przetwarza żądania za pomocą wzorca Razor MVC/pages. Terminal, jeśli żądanie pasuje do trasy.
OWIN Interop with OWIN-based apps, servers, and middleware (Interop with OWIN-based apps, servers, middleware) Terminal, jeśli oprogramowanie pośredniczące OWIN w pełni przetwarza żądanie.
Odpowiedź Buforowanie Zapewnia obsługę buforowania odpowiedzi. Przed składnikami, które wymagają buforowania. UseCORS Musi być przed UseResponseCaching .
Kompresja odpowiedzi Zapewnia obsługę kompresowania odpowiedzi. Przed składnikami, które wymagają kompresji.
Lokalizacja żądania Zapewnia obsługę lokalizacji. Przed lokalizacji poufnych składników. Musi pojawić się po oprogramowanie pośredniczące routingu w przypadku korzystania z programu RouteDataRequestCultureProvider .
Routing punktu końcowego Definiuje i ogranicza trasy żądań. Terminal do dopasowywania tras.
SPA Obsługuje wszystkie żądania z tego punktu w łańcuchu oprogramowania pośredniczącego, zwracając domyślną stronę dla aplikacji jednostronicowej (SPA) Pod koniec łańcucha pierwszeństwo ma inne oprogramowanie pośredniczące do obsługi plików statycznych, akcji MVC itp.
Sesja Zapewnia obsługę zarządzania sesjami użytkowników. Przed składnikami, które wymagają sesji.
Pliki statyczne Zapewnia obsługę plików statycznych i przeglądania katalogów. Terminal, jeśli żądanie pasuje do pliku.
Ponowne zapisywanie adresów URL Zapewnia obsługę ponownego zapisywania adresów URL i przekierowywania żądań. Przed składnikami, które zużywają adres URL.
Protokoły WebSocket Włącza protokół WebSocket. Przed składnikami wymaganymi do akceptowania żądań webSocket.

Dodatkowe zasoby