Bagikan melalui


ASP.NET Core Middleware

Catatan

Ini bukan versi terbaru dari artikel ini. Untuk rilis saat ini, lihat versi .NET 8 dari artikel ini.

Peringatan

Versi ASP.NET Core ini tidak lagi didukung. Untuk informasi selengkapnya, lihat Kebijakan Dukungan .NET dan .NET Core. Untuk rilis saat ini, lihat versi .NET 8 dari artikel ini.

Penting

Informasi ini berkaitan dengan produk pra-rilis yang mungkin dimodifikasi secara substansial sebelum dirilis secara komersial. Microsoft tidak memberikan jaminan, tersirat maupun tersurat, sehubungan dengan informasi yang diberikan di sini.

Untuk rilis saat ini, lihat versi .NET 8 dari artikel ini.

Oleh Rick Anderson dan Steve Smith

Middleware adalah perangkat lunak yang dirakit menjadi alur aplikasi untuk menangani permintaan dan respons. Setiap komponen:

  • Memilih apakah akan meneruskan permintaan ke komponen berikutnya dalam alur.
  • Dapat melakukan pekerjaan sebelum dan sesudah komponen berikutnya dalam alur.

Delegasi permintaan digunakan untuk membangun alur permintaan. Delegasi permintaan menangani setiap permintaan HTTP.

Delegasi permintaan dikonfigurasi menggunakan metode ekstensi Run, Map, dan Use. Delegasi permintaan individu dapat ditentukan dalam baris sebagai metode anonim (disebut middleware dalam baris), atau dapat didefinisikan dalam kelas yang dapat digunakan kembali. Kelas yang dapat digunakan kembali dan metode anonim dalam baris ini adalah middleware, yang juga disebut sebagai komponen middleware. Setiap komponen middleware dalam alur permintaan bertanggung jawab untuk memanggil komponen berikutnya dalam alur atau mengakhiri alur. Saat middleware diakhiri, ini disebut middleware terminal karena ini mencegah middleware berikutnya untuk memproses permintaan.

Migrasikan pengatur dan modul HTTP ke middleware ASP.NET Core menjelaskan perbedaan antara alur permintaan di ASP.NET Core dan ASP.NET 4.x dan menyediakan sampel middleware tambahan.

Analisis kode middleware

ASP.NET Core menyertakan banyak penganalisis platform kompiler yang memeriksa kualitas kode aplikasi. Untuk informasi lebih lanjut, lihat Analisis kode di aplikasi ASP.NET Core

Membuat saluran middleware dengan WebApplication

Alur permintaan ASP.NET Core terdiri dari urutan delegasi permintaan, yang dipanggil satu demi satu. Diagram berikut menunjukkan konsep tersebut. Utas eksekusi mengikuti panah hitam.

Pola pemrosesan permintaan yang menunjukkan permintaan tiba, pemrosesan melalui tiga middleware, dan respons meninggalkan aplikasi. Setiap middleware menjalankan logikanya dan menyerahkan permintaan ke middleware berikutnya pada pernyataan next(). Setelah middleware ketiga memproses permintaan, permintaan melewati kembali dua middleware sebelumnya dalam urutan terbalik untuk pemrosesan tambahan setelah pernyataan next() sebelum meninggalkan aplikasi sebagai respons terhadap klien.

Setiap delegasi dapat melakukan operasi sebelum dan sesudah delegasi berikutnya. Delegasi penanganan pengecualian harus dipanggil di awal alur, sehingga mereka dapat menangkap pengecualian yang terjadi di tahap selanjutnya dari alur.

Aplikasi ASP.NET Core yang paling sederhana menyiapkan delegasi permintaan tunggal yang menangani semua permintaan. Kasus ini tidak termasuk alur permintaan yang sebenarnya. Sebagai gantinya, satu fungsi anonim dipanggil sebagai respons terhadap setiap permintaan HTTP.

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

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

app.Run();

Tautkan beberapa delegasi permintaan bersama dengan Use. Parameter next mewakili delegasi berikutnya dalam alur. Anda dapat mengakhiri alur dengan tidak memanggil parameter next. Anda biasanya dapat melakukan tindakan sebelum dan sesudah delegasi next, seperti yang diperlihatkan contoh berikut:

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

app.Use(async (context, next) =>
{
    // Do work that can 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();

Sirkuit pendek alur permintaan

Saat delegasi tidak meneruskan permintaan ke delegasi berikutnya, hal itu disebut mengakhiri alur permintaan. Memutus hubungan sering kali diperlukan karena akan menghindari pekerjaan yang tidak perlu. Misalnya, Middleware File Statis dapat bertindak sebagai middleware terminal dengan memproses permintaan untuk file statis dan mengakhiri sisa alur. Middleware yang ditambahkan ke alur sebelum middleware yang menghentikan pemrosesan lebih lanjut masih memproses kode setelah pernyataan next.Invoke-nya. Namun, lihat peringatan berikut tentang mencoba menulis ke respons yang telah dikirim.

Peringatan

Jangan menelepon next.Invoke selama atau setelah respons dikirim ke klien. HttpResponse Setelah dimulai, perubahan menghasilkan pengecualian. Misalnya, mengatur header dan kode status melemparkan pengecualian setelah respons dimulai. Menulis ke isi respons setelah memanggil next:

  • Dapat menyebabkan pelanggaran protokol, seperti menulis lebih dari yang dinyatakan Content-Length.
  • Dapat merusak format isi, seperti menulis footer HTML ke file CSS.

HasStarted adalah petunjuk yang berguna untuk menunjukkan apakah header telah dikirim atau isi telah ditulis.

Untuk informasi selengkapnya, lihat Middleware sirkuit pendek setelah perutean.

Run Delegasi

Delegasi Run tidak menerima parameter next. Delegasi Run pertama selalu terminal dan mengakhiri alur. Run adalah sebuah konvensi. Beberapa komponen middleware dapat mengekspos metode Run[Middleware] yang berjalan di akhir alur:

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

app.Use(async (context, next) =>
{
    // Do work that can 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();

Jika Anda ingin melihat komentar kode yang diterjemahkan ke bahasa selain bahasa Inggris, beri tahu kami dalam masalah diskusi GitHub ini.

Dalam contoh sebelumnya, delegasi Run menulis "Hello from 2nd delegate." ke respons dan kemudian mengakhiri alur. Jika delegasi Use atau Run lain ditambahkan setelah delegasi Run, delegasi tersebut tidak dipanggil.

Lebih memilih overload app.Use yang mengharuskan penerusan konteks ke berikutnya

Metode ekstensi app.Use yang tidak dialokasikan:

  • Mengharuskan penerusan konteks ke next.
  • Menyimpan dua alokasi per permintaan internal yang diperlukan saat menggunakan overload lainnya.

Untuk informasi lebih lanjut, lihat masalah GitHub ini.

Urutan middleware

Diagram berikut menunjukkan alur pemrosesan permintaan lengkap untuk aplikasi ASP.NET Core MVC dan Razor Pages. Anda dapat melihat bagaimana, dalam aplikasi pada umumnya, middleware yang ada diurutkan dan di mana middleware kustom ditambahkan. Anda memiliki kendali penuh dalam bagaimana cara mengurutkan kembali middleware yang ada atau menyuntikkan middleware kustom baru yang diperlukan untuk skenario Anda.

Alur middleware ASP.NET Core

Middleware Titik akhir dalam diagram sebelumnya menjalankan alur filter untuk jenis aplikasi yang sesuai—MVC atau Razor Pages.

Middleware Perutean dalam diagram sebelumnya ditunjukkan mengikuti File Statis. Ini adalah urutan yang diimplementasikan oleh template proyek dengan memanggil app.UseRouting secara eksplisit. Jika Anda tidak memanggil app.UseRouting, middleware Perutean berjalan di awal alur secara default. Untuk informasi selengkapnya, lihat Perutean.

Alur filter ASP.NET Core

Urutan penambahan komponen middleware dalam file Program.cs menentukan urutan komponen middleware dipanggil pada permintaan dan urutan terbalik untuk respons. Urutan ini penting untuk keamanan, performa, dan fungsionalitas.

Kode yang disorot berikut ini di Program.cs menambahkan komponen middleware terkait keamanan dalam urutan yang disarankan pada umumnya:

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

var builder = WebApplication.CreateBuilder(args);

var connectionString = builder.Configuration.GetConnectionString("DefaultConnection")
    ?? throw new InvalidOperationException("Connection string 'DefaultConnection' not found.");
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();
builder.Services.AddControllersWithViews();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseMigrationsEndPoint();
}
else
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

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

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

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

app.MapRazorPages();
app.MapDefaultControllerRoute();

app.Run();

Dalam kode sebelumnya:

  • Middleware yang tidak ditambahkan saat membuat aplikasi web baru dengan akun pengguna individu dikomentari.
  • Tidak setiap middleware muncul dalam urutan yang persis seperti ini, tetapi banyak yang demikian. Misalnya:
    • UseCors, UseAuthentication, dan UseAuthorization harus muncul dalam urutan yang ditampilkan.
    • UseCors saat ini harus muncul sebelum UseResponseCaching. Persyaratan ini dijelaskan dalam Masalah GitHub dotnet/aspnetcore #23218.
    • UseRequestLocalization harus muncul sebelum middleware apa pun yang mungkin memeriksa budaya permintaan, misalnya, app.UseStaticFiles().
    • UseRateLimiter harus dipanggil setelah UseRouting ketika pembatasan laju API tertentu titik akhir digunakan. Misalnya, jika [EnableRateLimiting] atribut digunakan, UseRateLimiter harus dipanggil setelah UseRouting. Saat hanya memanggil pembatas global, UseRateLimiter dapat dipanggil sebelum UseRouting.

Dalam beberapa skenario, middleware memiliki urutan yang berbeda. Misalnya, pengurutan penembolokan dan pemadatan adalah skenario khusus, dan ada beberapa pengurutan yang valid. Contohnya:

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

Dengan kode sebelumnya, penggunaan CPU dapat dikurangi dengan melakukan penembolokan pada respons yang dipadatkan, tetapi Anda mungkin akan melakukan penembolokan beberapa representasi sumber daya menggunakan algoritma pemadatan yang berbeda seperti Gzip atau Brotli.

Urutan berikut menggabungkan file statis untuk memungkinkan penembolokan file statis yang dipadatkan:

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

Kode Program.cs berikut menambahkan komponen middleware untuk skenario aplikasi umum:

  1. Penanganan pengecualian/kesalahan
    • Saat aplikasi berjalan di lingkungan Pengembangan:
      • Middleware Halaman Pengecualian Pengembang (UseDeveloperExceptionPage) melaporkan kesalahan runtime bahasa umum aplikasi.
      • Middleware Halaman Kesalahan Database (UseDatabaseErrorPage) melaporkan kesalahan runtime bahasa umum database.
    • Saat aplikasi berjalan di lingkungan Produksi:
      • Middleware Penanganan Pengecualian (UseExceptionHandler) menangkap pengecualian yang ditampilkan ke middleware berikut.
      • Middleware HTTP Strict Transport Security Protocol (HSTS) (UseHsts) menambahkan header Strict-Transport-Security.
  2. Middleware Pengalihan HTTPS (UseHttpsRedirection) mengalihkan permintaan HTTP ke HTTPS.
  3. Middleware File Statis (UseStaticFiles) mengembalikan file statis dan mengakhiri pemrosesan permintaan lebih lanjut.
  4. Middleware Kebijakan Cookie (UseCookiePolicy) menyesuaikan aplikasi dengan Peraturan Perlindungan Data Umum (GDPR) Eropa.
  5. Middleware Perutean (UseRouting) untuk merutekan permintaan.
  6. Middleware Autentikasi (UseAuthentication) mencoba mengautentikasi pengguna sebelum mereka diizinkan mengakses sumber daya yang aman.
  7. Middleware Otorisasi (UseAuthorization) memberi wewenang kepada pengguna untuk mengakses sumber daya yang aman.
  8. Middleware Sesi (UseSession) menetapkan dan mempertahankan keadaan sesi. Jika aplikasi menggunakan keadaan sesi, panggil Middleware Sesi setelah Middleware Kebijakan Cookie dan sebelum Middleware MVC.
  9. Middleware Perutean Titik Akhir (UseEndpoints dengan MapRazorPages) untuk menambahkan titik akhir Razor Pages ke alur permintaan.
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();

Dalam kode contoh sebelumnya, setiap metode ekstensi middleware diekspos pada WebApplicationBuilder melalui namespace layanan Microsoft.AspNetCore.Builder.

UseExceptionHandler adalah komponen middleware pertama yang ditambahkan ke alur. Oleh karena itu, Middleware Penanganan Pengecualian menangkap pengecualian yang terjadi di panggilan berikutnya.

Middleware File Statis dipanggil di awal alur sehingga dapat menangani permintaan dan mengakhiri tanpa melalui komponen yang tersisa. Middleware File Statis tidak menyediakan pemeriksaan otorisasi. File apa pun yang disajikan oleh Middleware File Statis, termasuk yang berada di bawah wwwroot, tersedia untuk umum. Untuk pendekatan pengamanan file statis, lihat File statis di ASP.NET Core.

Jika permintaan tidak ditangani oleh Middleware File Statis, permintaan akan diteruskan ke Middleware Autentikasi (UseAuthentication), yang melakukan autentikasi. Autentikasi tidak mengakhiri permintaan yang tidak diautentikasi. Meskipun Middleware Autentikasi mengautentikasi permintaan, otorisasi (dan penolakan) hanya terjadi setelah MVC memilih Razor Page atau pengontrol dan tindakan MVC tertentu.

Contoh berikut menunjukkan urutan middleware di mana permintaan untuk file statis ditangani oleh Middleware File Statis sebelum Middleware Pemadatan Respons. File statis tidak dipadatkan dengan urutan middleware ini. Respons Razor Pages dapat dipadatkan.

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

app.UseRouting();

app.UseResponseCompression();

app.MapRazorPages();

Untuk informasi tentang Aplikasi Halaman Tunggal, lihat Gambaran Umum Aplikasi Halaman Tunggal (SPAs) di ASP.NET Core.

Urutan UseCors dan UseStaticFiles

Urutan untuk memanggil UseCors dan UseStaticFiles bergantung pada aplikasi. Untuk informasi lebih lanjut, lihat Urutan UseCors dan UseStaticFiles

Urutan Middleware Header yang Diteruskan

Middleware Header yang Diteruskan harus dijalankan sebelum middleware lainnya. Urutan ini memastikan bahwa middleware yang mengandalkan informasi header yang diteruskan dapat menggunakan nilai header untuk pemrosesan. Untuk menjalankan Middleware Header yang Diteruskan setelah middleware diagnostik dan penanganan kesalahan, lihat Urutan Middleware Header yang Diteruskan.

Membuat cabang alur middleware

Ekstensi Map digunakan sebagai konvensi untuk membuat cabang alur. Map membuat cabang alur permintaan berdasarkan pencocokan jalur permintaan yang diberikan. Jika jalur permintaan dimulai dengan jalur yang diberikan, cabang akan dijalankan.

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.");
});

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");
    });
}

Tabel berikut menunjukkan permintaan dan respons dari http://localhost:1234 menggunakan kode sebelumnya.

Permintaan Respons
localhost:1234 Halo dari delegasi non-Peta.
localhost:1234/map1 Pengujian Peta 1
localhost:1234/map2 Pengujian Peta 2
localhost:1234/map3 Halo dari delegasi non-Peta.

Saat Map digunakan, segmen jalur yang cocok akan dihapus dari HttpRequest.Path dan ditambahkan ke HttpRequest.PathBase untuk setiap permintaan.

Map mendukung bersarang, misalnya:

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

Map juga dapat mencocokkan beberapa segmen sekaligus:

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.");
});

app.Run();

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

MapWhen membuat cabang alur permintaan berdasarkan hasil dari predikat yang diberikan. Semua predikat berjenis Func<HttpContext, bool> dapat digunakan untuk memetakan permintaan ke cabang baru dari alur. Dalam contoh berikut, predikat digunakan untuk mendeteksi keberadaan variabel string kueri branch:

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

app.MapWhen(context => context.Request.Query.ContainsKey("branch"), HandleBranch);

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

app.Run();

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

Tabel berikut menunjukkan permintaan dan respons dari http://localhost:1234 menggunakan kode sebelumnya:

Permintaan Respons
localhost:1234 Hello from non-Map delegate.
localhost:1234/?branch=main Branch used = main

UseWhen juga membuat cabang alur permintaan berdasarkan hasil dari predikat yang diberikan. Tidak seperti MapWhen, cabang ini digabungkan kembali ke alur utama jika tidak diakhiri atau berisi middleware terminal:

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.");
});

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.
    });
}

Dalam contoh sebelumnya, respons Hello from non-Map delegate. ditulis untuk semua permintaan. Jika permintaan menyertakan branch variabel string kueri, nilainya dicatat sebelum alur utama bergabung kembali.

Middleware bawaan

ASP.NET Core dikirimkan dengan komponen middleware berikut. Kolom Urutan memberikan catatan tentang penempatan middleware di alur pemrosesan permintaan dan dalam kondisi apa middleware dapat menghentikan pemrosesan permintaan. Saat middleware mengakhiri alur pemrosesan permintaan dan mencegah middleware downstream berikutnya memproses permintaan, itu disebut middleware terminal. Untuk informasi selengkapnya tentang sirkuit pendek, lihat bagian Membuat alur middleware dengan WebApplication .

Middleware Deskripsi Pesanan
Autentikasi Menyediakan dukungan autentikasi. Sebelum HttpContext.User diperlukan. Terminal untuk panggilan balik OAuth.
Otorisasi Menyediakan dukungan otorisasi. Segera setelah Middleware Autentikasi.
Kebijakan Cookie Melacak persetujuan dari pengguna untuk menyimpan informasi pribadi dan menerapkan standar minimum untuk bidang cookie, seperti secure dan SameSite. Sebelum middleware yang mengeluarkan cookie. Contoh: Autentikasi, Sesi, MVC (TempData).
CORS Mengonfigurasi Cross-Origin Resource Sharing. Sebelum komponen yang menggunakan CORS. UseCors saat ini harus sebelum UseResponseCaching karena bug ini.
DeveloperExceptionPage Menghasilkan halaman dengan informasi kesalahan yang dimaksudkan untuk digunakan hanya di lingkungan Pengembangan. Sebelum komponen yang menghasilkan kesalahan. Template proyek secara otomatis mendaftarkan middleware ini sebagai middleware pertama dalam alur saat lingkungan sedang dalam Pengembangan.
Diagnostik Beberapa middleware terpisah yang menyediakan halaman pengecualian pengembang, penanganan pengecualian, halaman kode status, dan halaman web default untuk aplikasi baru. Sebelum komponen yang menghasilkan kesalahan. Terminal untuk pengecualian atau menyajikan halaman web default untuk aplikasi baru.
Header yang Diteruskan Meneruskan header yang diproksi ke permintaan saat ini. Sebelum komponen yang menggunakan bidang yang diperbarui. Contoh: skema, host, IP klien, metode.
Pemeriksaan Kesehatan Memeriksa kesehatan aplikasi ASP.NET Core dan dependensinya, seperti memeriksa ketersediaan database. Terminal jika permintaan cocok dengan titik akhir pemeriksaan kesehatan.
Propagasi Header Mempropagasi header HTTP dari permintaan masuk ke permintaan Klien HTTP keluar.
Pengelogan HTTP Mencatat Permintaan dan Respons HTTP. Pada awal alur middleware.
Penimpaan Metode HTTP Mengizinkan permintaan POST yang masuk untuk menimpa metode. Sebelum komponen yang menggunakan metode yang diperbarui.
Pengalihan HTTPS Mengalihkan semua permintaan HTTP ke HTTPS. Sebelum komponen yang menggunakan URL.
HTTP Strict Transport Security (HSTS) Middleware peningkatan keamanan yang menambahkan header respons khusus. Sebelum respons dikirim dan setelah komponen yang mengubah permintaan. Contoh: Header yang Diteruskan, Penulisan Ulang URL.
MVC Memproses permintaan dengan MVC/Razor Pages. Terminal jika permintaan cocok dengan rute.
OWIN Interop dengan aplikasi, server, dan middleware berbasis OWIN. Terminal jika Middleware OWIN sepenuhnya memproses permintaan.
Penembolokan Output Menyediakan dukungan untuk respons penembolokan berdasarkan konfigurasi. Sebelum komponen yang membutuhkan penembolokan. UseRouting harus sebelum UseOutputCaching. UseCORS harus sebelum UseOutputCaching.
Penembolokan Respons Menyediakan dukungan untuk respons penembolokan. Ini mengharuskan partisipasi klien berfungsi. Gunakan penembolokan output untuk kontrol server lengkap. Sebelum komponen yang membutuhkan penembolokan. UseCORS harus sebelum UseResponseCaching. Biasanya tidak bermanfaat untuk aplikasi UI seperti Razor Pages karena browser umumnya mengatur header permintaan yang mencegah penembolokan. Manfaat penembolokan output aplikasi UI.
Dekompresi Permintaan Menyediakan dukungan untuk mendekompresi permintaan. Sebelum komponen yang membaca isi permintaan.
Pemadatan Respons Memberikan dukungan untuk memadatkan respons. Sebelum komponen yang membutuhkan pemadatan.
Pelokalan Permintaan Menyediakan dukungan pelokalan. Sebelum komponen sensitif pelokalan. Harus muncul setelah Middleware Perutean saat menggunakan RouteDataRequestCultureProvider.
Batas Waktu Permintaan Menyediakan dukungan untuk mengonfigurasi batas waktu permintaan, global, dan per titik akhir. UseRequestTimeouts harus datang setelah UseExceptionHandler, UseDeveloperExceptionPage, dan UseRouting.
Perutean Titik Akhir Mendefinisikan dan membatasi rute permintaan. Terminal untuk rute yang cocok.
SPA Menangani semua permintaan dari titik ini dalam rantai middleware dengan mengembalikan halaman default untuk Aplikasi Halaman Tunggal (SPA) Pada bagian akhir rantai, sehingga middleware lain untuk penyajian file statis, tindakan MVC, dll., diutamakan.
Sesi Menyediakan dukungan untuk mengelola sesi pengguna. Sebelum komponen yang membutuhkan Sesi.
File Statis Menyediakan dukungan untuk menyajikan file statis dan penjelajahan direktori. Terminal jika permintaan cocok dengan file.
Penulisan Ulang URL Memberikan dukungan untuk menulis kembali URL dan mengalihkan permintaan. Sebelum komponen yang menggunakan URL.
W3CLogging Menghasilkan log akses server dalam Format File Log yang Diperluas W3C. Pada awal alur middleware.
WebSocket Mengaktifkan protokol WebSocket. Sebelum komponen yang diperlukan untuk menerima permintaan WebSocket.

Sumber Daya Tambahan:

Oleh Rick Anderson dan Steve Smith

Middleware adalah perangkat lunak yang dirakit menjadi alur aplikasi untuk menangani permintaan dan respons. Setiap komponen:

  • Memilih apakah akan meneruskan permintaan ke komponen berikutnya dalam alur.
  • Dapat melakukan pekerjaan sebelum dan sesudah komponen berikutnya dalam alur.

Delegasi permintaan digunakan untuk membangun alur permintaan. Delegasi permintaan menangani setiap permintaan HTTP.

Delegasi permintaan dikonfigurasi menggunakan metode ekstensi Run, Map, dan Use. Delegasi permintaan individu dapat ditentukan dalam baris sebagai metode anonim (disebut middleware dalam baris), atau dapat didefinisikan dalam kelas yang dapat digunakan kembali. Kelas yang dapat digunakan kembali dan metode anonim dalam baris ini adalah middleware, yang juga disebut sebagai komponen middleware. Setiap komponen middleware dalam alur permintaan bertanggung jawab untuk memanggil komponen berikutnya dalam alur atau mengakhiri alur. Saat middleware diakhiri, ini disebut middleware terminal karena ini mencegah middleware berikutnya untuk memproses permintaan.

Migrasikan pengatur dan modul HTTP ke middleware ASP.NET Core menjelaskan perbedaan antara alur permintaan di ASP.NET Core dan ASP.NET 4.x dan menyediakan sampel middleware tambahan.

Analisis kode middleware

ASP.NET Core menyertakan banyak penganalisis platform kompiler yang memeriksa kualitas kode aplikasi. Untuk informasi lebih lanjut, lihat Analisis kode di aplikasi ASP.NET Core

Membuat saluran middleware dengan WebApplication

Alur permintaan ASP.NET Core terdiri dari urutan delegasi permintaan, yang dipanggil satu demi satu. Diagram berikut menunjukkan konsep tersebut. Utas eksekusi mengikuti panah hitam.

Pola pemrosesan permintaan yang menunjukkan permintaan tiba, pemrosesan melalui tiga middleware, dan respons meninggalkan aplikasi. Setiap middleware menjalankan logikanya dan menyerahkan permintaan ke middleware berikutnya pada pernyataan next(). Setelah middleware ketiga memproses permintaan, permintaan melewati kembali dua middleware sebelumnya dalam urutan terbalik untuk pemrosesan tambahan setelah pernyataan next() sebelum meninggalkan aplikasi sebagai respons terhadap klien.

Setiap delegasi dapat melakukan operasi sebelum dan sesudah delegasi berikutnya. Delegasi penanganan pengecualian harus dipanggil di awal alur, sehingga mereka dapat menangkap pengecualian yang terjadi di tahap selanjutnya dari alur.

Aplikasi ASP.NET Core yang paling sederhana menyiapkan delegasi permintaan tunggal yang menangani semua permintaan. Kasus ini tidak termasuk alur permintaan yang sebenarnya. Sebagai gantinya, satu fungsi anonim dipanggil sebagai respons terhadap setiap permintaan HTTP.

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

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

app.Run();

Tautkan beberapa delegasi permintaan bersama dengan Use. Parameter next mewakili delegasi berikutnya dalam alur. Anda dapat mengakhiri alur dengan tidak memanggil parameter next. Anda biasanya dapat melakukan tindakan sebelum dan sesudah delegasi next, seperti yang diperlihatkan contoh berikut:

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

app.Use(async (context, next) =>
{
    // Do work that can 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();

Saat delegasi tidak meneruskan permintaan ke delegasi berikutnya, hal itu disebut mengakhiri alur permintaan. Memutus hubungan sering kali diperlukan karena akan menghindari pekerjaan yang tidak perlu. Misalnya, Middleware File Statis dapat bertindak sebagai middleware terminal dengan memproses permintaan untuk file statis dan mengakhiri sisa alur. Middleware yang ditambahkan ke alur sebelum middleware yang menghentikan pemrosesan lebih lanjut masih memproses kode setelah pernyataan next.Invoke-nya. Namun, lihat peringatan berikut tentang mencoba menulis ke respons yang telah dikirim.

Peringatan

Jangan panggil next.Invoke setelah respons dikirim ke klien. Perubahan ke HttpResponse setelah respons dimulai akan memunculkan pengecualian. Misalnya, mengatur header dan kode status akan memunculkan pengecualian. Menulis ke isi respons setelah memanggil next:

  • Dapat menyebabkan pelanggaran protokol. Misalnya, menulis lebih dari Content-Length yang dinyatakan.
  • Dapat merusak format isi. Misalnya, menulis catatan kaki HTML ke file CSS.

HasStarted adalah petunjuk yang berguna untuk menunjukkan apakah header telah dikirim atau isi telah ditulis.

Delegasi Run tidak menerima parameter next. Delegasi Run pertama selalu terminal dan mengakhiri alur. Run adalah sebuah konvensi. Beberapa komponen middleware dapat mengekspos metode Run[Middleware] yang berjalan di akhir alur:

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

app.Use(async (context, next) =>
{
    // Do work that can 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();

Jika Anda ingin melihat komentar kode yang diterjemahkan ke bahasa selain bahasa Inggris, beri tahu kami dalam masalah diskusi GitHub ini.

Dalam contoh sebelumnya, delegasi Run menulis "Hello from 2nd delegate." ke respons dan kemudian mengakhiri alur. Jika delegasi Use atau Run lain ditambahkan setelah delegasi Run, delegasi tersebut tidak dipanggil.

Lebih memilih overload app.Use yang mengharuskan penerusan konteks ke berikutnya

Metode ekstensi app.Use yang tidak dialokasikan:

  • Mengharuskan penerusan konteks ke next.
  • Menyimpan dua alokasi per permintaan internal yang diperlukan saat menggunakan overload lainnya.

Untuk informasi lebih lanjut, lihat masalah GitHub ini.

Urutan middleware

Diagram berikut menunjukkan alur pemrosesan permintaan lengkap untuk aplikasi ASP.NET Core MVC dan Razor Pages. Anda dapat melihat bagaimana, dalam aplikasi pada umumnya, middleware yang ada diurutkan dan di mana middleware kustom ditambahkan. Anda memiliki kendali penuh dalam bagaimana cara mengurutkan kembali middleware yang ada atau menyuntikkan middleware kustom baru yang diperlukan untuk skenario Anda.

Alur middleware ASP.NET Core

Middleware Titik akhir dalam diagram sebelumnya menjalankan alur filter untuk jenis aplikasi yang sesuai—MVC atau Razor Pages.

Middleware Perutean dalam diagram sebelumnya ditunjukkan mengikuti File Statis. Ini adalah urutan yang diimplementasikan oleh template proyek dengan memanggil app.UseRouting secara eksplisit. Jika Anda tidak memanggil app.UseRouting, middleware Perutean berjalan di awal alur secara default. Untuk informasi selengkapnya, lihat Perutean.

Alur filter ASP.NET Core

Urutan penambahan komponen middleware dalam file Program.cs menentukan urutan komponen middleware dipanggil pada permintaan dan urutan terbalik untuk respons. Urutan ini penting untuk keamanan, performa, dan fungsionalitas.

Kode yang disorot berikut ini di Program.cs menambahkan komponen middleware terkait keamanan dalam urutan yang disarankan pada umumnya:

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

var builder = WebApplication.CreateBuilder(args);

var connectionString = builder.Configuration.GetConnectionString("DefaultConnection")
    ?? throw new InvalidOperationException("Connection string 'DefaultConnection' not found.");
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();
builder.Services.AddControllersWithViews();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseMigrationsEndPoint();
}
else
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

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

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

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

app.MapRazorPages();
app.MapDefaultControllerRoute();

app.Run();

Dalam kode sebelumnya:

  • Middleware yang tidak ditambahkan saat membuat aplikasi web baru dengan akun pengguna individu dikomentari.
  • Tidak setiap middleware muncul dalam urutan yang persis seperti ini, tetapi banyak yang demikian. Misalnya:
    • UseCors, UseAuthentication, dan UseAuthorization harus muncul dalam urutan yang ditampilkan.
    • UseCors saat ini harus muncul sebelum UseResponseCaching. Persyaratan ini dijelaskan dalam Masalah GitHub dotnet/aspnetcore #23218.
    • UseRequestLocalization harus muncul sebelum middleware apa pun yang mungkin memeriksa budaya permintaan, misalnya, app.UseStaticFiles().
    • UseRateLimiter harus dipanggil setelah UseRouting ketika pembatasan laju API tertentu titik akhir digunakan. Misalnya, jika [EnableRateLimiting] atribut digunakan, UseRateLimiter harus dipanggil setelah UseRouting. Saat hanya memanggil pembatas global, UseRateLimiter dapat dipanggil sebelum UseRouting.

Dalam beberapa skenario, middleware memiliki urutan yang berbeda. Misalnya, pengurutan penembolokan dan pemadatan adalah skenario khusus, dan ada beberapa pengurutan yang valid. Contohnya:

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

Dengan kode sebelumnya, penggunaan CPU dapat dikurangi dengan melakukan penembolokan pada respons yang dipadatkan, tetapi Anda mungkin akan melakukan penembolokan beberapa representasi sumber daya menggunakan algoritma pemadatan yang berbeda seperti Gzip atau Brotli.

Urutan berikut menggabungkan file statis untuk memungkinkan penembolokan file statis yang dipadatkan:

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

Kode Program.cs berikut menambahkan komponen middleware untuk skenario aplikasi umum:

  1. Penanganan pengecualian/kesalahan
    • Saat aplikasi berjalan di lingkungan Pengembangan:
      • Middleware Halaman Pengecualian Pengembang (UseDeveloperExceptionPage) melaporkan kesalahan runtime bahasa umum aplikasi.
      • Middleware Halaman Kesalahan Database (UseDatabaseErrorPage) melaporkan kesalahan runtime bahasa umum database.
    • Saat aplikasi berjalan di lingkungan Produksi:
      • Middleware Penanganan Pengecualian (UseExceptionHandler) menangkap pengecualian yang ditampilkan ke middleware berikut.
      • Middleware HTTP Strict Transport Security Protocol (HSTS) (UseHsts) menambahkan header Strict-Transport-Security.
  2. Middleware Pengalihan HTTPS (UseHttpsRedirection) mengalihkan permintaan HTTP ke HTTPS.
  3. Middleware File Statis (UseStaticFiles) mengembalikan file statis dan mengakhiri pemrosesan permintaan lebih lanjut.
  4. Middleware Kebijakan Cookie (UseCookiePolicy) menyesuaikan aplikasi dengan Peraturan Perlindungan Data Umum (GDPR) Eropa.
  5. Middleware Perutean (UseRouting) untuk merutekan permintaan.
  6. Middleware Autentikasi (UseAuthentication) mencoba mengautentikasi pengguna sebelum mereka diizinkan mengakses sumber daya yang aman.
  7. Middleware Otorisasi (UseAuthorization) memberi wewenang kepada pengguna untuk mengakses sumber daya yang aman.
  8. Middleware Sesi (UseSession) menetapkan dan mempertahankan keadaan sesi. Jika aplikasi menggunakan keadaan sesi, panggil Middleware Sesi setelah Middleware Kebijakan Cookie dan sebelum Middleware MVC.
  9. Middleware Perutean Titik Akhir (UseEndpoints dengan MapRazorPages) untuk menambahkan titik akhir Razor Pages ke alur permintaan.
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();

Dalam kode contoh sebelumnya, setiap metode ekstensi middleware diekspos pada WebApplicationBuilder melalui namespace layanan Microsoft.AspNetCore.Builder.

UseExceptionHandler adalah komponen middleware pertama yang ditambahkan ke alur. Oleh karena itu, Middleware Penanganan Pengecualian menangkap pengecualian yang terjadi di panggilan berikutnya.

Middleware File Statis dipanggil di awal alur sehingga dapat menangani permintaan dan mengakhiri tanpa melalui komponen yang tersisa. Middleware File Statis tidak menyediakan pemeriksaan otorisasi. File apa pun yang disajikan oleh Middleware File Statis, termasuk yang berada di bawah wwwroot, tersedia untuk umum. Untuk pendekatan pengamanan file statis, lihat File statis di ASP.NET Core.

Jika permintaan tidak ditangani oleh Middleware File Statis, permintaan akan diteruskan ke Middleware Autentikasi (UseAuthentication), yang melakukan autentikasi. Autentikasi tidak mengakhiri permintaan yang tidak diautentikasi. Meskipun Middleware Autentikasi mengautentikasi permintaan, otorisasi (dan penolakan) hanya terjadi setelah MVC memilih Razor Page atau pengontrol dan tindakan MVC tertentu.

Contoh berikut menunjukkan urutan middleware di mana permintaan untuk file statis ditangani oleh Middleware File Statis sebelum Middleware Pemadatan Respons. File statis tidak dipadatkan dengan urutan middleware ini. Respons Razor Pages dapat dipadatkan.

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

app.UseRouting();

app.UseResponseCompression();

app.MapRazorPages();

Untuk informasi tentang Aplikasi Halaman Tunggal, lihat panduan untuk template proyek React dan Angular.

Urutan UseCors dan UseStaticFiles

Urutan untuk memanggil UseCors dan UseStaticFiles bergantung pada aplikasi. Untuk informasi lebih lanjut, lihat Urutan UseCors dan UseStaticFiles

Urutan Middleware Header yang Diteruskan

Middleware Header yang Diteruskan harus dijalankan sebelum middleware lainnya. Urutan ini memastikan bahwa middleware yang mengandalkan informasi header yang diteruskan dapat menggunakan nilai header untuk pemrosesan. Untuk menjalankan Middleware Header yang Diteruskan setelah middleware diagnostik dan penanganan kesalahan, lihat Urutan Middleware Header yang Diteruskan.

Membuat cabang alur middleware

Ekstensi Map digunakan sebagai konvensi untuk membuat cabang alur. Map membuat cabang alur permintaan berdasarkan pencocokan jalur permintaan yang diberikan. Jika jalur permintaan dimulai dengan jalur yang diberikan, cabang akan dijalankan.

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.");
});

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");
    });
}

Tabel berikut menunjukkan permintaan dan respons dari http://localhost:1234 menggunakan kode sebelumnya.

Permintaan Respons
localhost:1234 Halo dari delegasi non-Peta.
localhost:1234/map1 Pengujian Peta 1
localhost:1234/map2 Pengujian Peta 2
localhost:1234/map3 Halo dari delegasi non-Peta.

Saat Map digunakan, segmen jalur yang cocok akan dihapus dari HttpRequest.Path dan ditambahkan ke HttpRequest.PathBase untuk setiap permintaan.

Map mendukung bersarang, misalnya:

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

Map juga dapat mencocokkan beberapa segmen sekaligus:

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.");
});

app.Run();

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

MapWhen membuat cabang alur permintaan berdasarkan hasil dari predikat yang diberikan. Semua predikat berjenis Func<HttpContext, bool> dapat digunakan untuk memetakan permintaan ke cabang baru dari alur. Dalam contoh berikut, predikat digunakan untuk mendeteksi keberadaan variabel string kueri branch:

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

app.MapWhen(context => context.Request.Query.ContainsKey("branch"), HandleBranch);

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

app.Run();

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

Tabel berikut menunjukkan permintaan dan respons dari http://localhost:1234 menggunakan kode sebelumnya:

Permintaan Respons
localhost:1234 Hello from non-Map delegate.
localhost:1234/?branch=main Branch used = main

UseWhen juga membuat cabang alur permintaan berdasarkan hasil dari predikat yang diberikan. Tidak seperti MapWhen, cabang ini digabungkan kembali ke alur utama jika tidak diakhiri atau berisi middleware terminal:

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.");
});

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.
    });
}

Dalam contoh sebelumnya, respons Hello from non-Map delegate. ditulis untuk semua permintaan. Jika permintaan menyertakan branch variabel string kueri, nilainya dicatat sebelum alur utama bergabung kembali.

Middleware bawaan

ASP.NET Core dikirimkan dengan komponen middleware berikut. Kolom Urutan memberikan catatan tentang penempatan middleware di alur pemrosesan permintaan dan dalam kondisi apa middleware dapat menghentikan pemrosesan permintaan. Saat middleware mengakhiri alur pemrosesan permintaan dan mencegah middleware downstream berikutnya memproses permintaan, itu disebut middleware terminal. Untuk informasi selengkapnya tentang sirkuit pendek, lihat bagian Membuat alur middleware dengan WebApplication .

Middleware Deskripsi Pesanan
Autentikasi Menyediakan dukungan autentikasi. Sebelum HttpContext.User diperlukan. Terminal untuk panggilan balik OAuth.
Otorisasi Menyediakan dukungan otorisasi. Segera setelah Middleware Autentikasi.
Kebijakan Cookie Melacak persetujuan dari pengguna untuk menyimpan informasi pribadi dan menerapkan standar minimum untuk bidang cookie, seperti secure dan SameSite. Sebelum middleware yang mengeluarkan cookie. Contoh: Autentikasi, Sesi, MVC (TempData).
CORS Mengonfigurasi Cross-Origin Resource Sharing. Sebelum komponen yang menggunakan CORS. UseCors saat ini harus sebelum UseResponseCaching karena bug ini.
DeveloperExceptionPage Menghasilkan halaman dengan informasi kesalahan yang dimaksudkan untuk digunakan hanya di lingkungan Pengembangan. Sebelum komponen yang menghasilkan kesalahan. Template proyek secara otomatis mendaftarkan middleware ini sebagai middleware pertama dalam alur saat lingkungan sedang dalam Pengembangan.
Diagnostik Beberapa middleware terpisah yang menyediakan halaman pengecualian pengembang, penanganan pengecualian, halaman kode status, dan halaman web default untuk aplikasi baru. Sebelum komponen yang menghasilkan kesalahan. Terminal untuk pengecualian atau menyajikan halaman web default untuk aplikasi baru.
Header yang Diteruskan Meneruskan header yang diproksi ke permintaan saat ini. Sebelum komponen yang menggunakan bidang yang diperbarui. Contoh: skema, host, IP klien, metode.
Pemeriksaan Kesehatan Memeriksa kesehatan aplikasi ASP.NET Core dan dependensinya, seperti memeriksa ketersediaan database. Terminal jika permintaan cocok dengan titik akhir pemeriksaan kesehatan.
Propagasi Header Mempropagasi header HTTP dari permintaan masuk ke permintaan Klien HTTP keluar.
Pengelogan HTTP Mencatat Permintaan dan Respons HTTP. Pada awal alur middleware.
Penimpaan Metode HTTP Mengizinkan permintaan POST yang masuk untuk menimpa metode. Sebelum komponen yang menggunakan metode yang diperbarui.
Pengalihan HTTPS Mengalihkan semua permintaan HTTP ke HTTPS. Sebelum komponen yang menggunakan URL.
HTTP Strict Transport Security (HSTS) Middleware peningkatan keamanan yang menambahkan header respons khusus. Sebelum respons dikirim dan setelah komponen yang mengubah permintaan. Contoh: Header yang Diteruskan, Penulisan Ulang URL.
MVC Memproses permintaan dengan MVC/Razor Pages. Terminal jika permintaan cocok dengan rute.
OWIN Interop dengan aplikasi, server, dan middleware berbasis OWIN. Terminal jika Middleware OWIN sepenuhnya memproses permintaan.
Penembolokan Output Menyediakan dukungan untuk respons penembolokan berdasarkan konfigurasi. Sebelum komponen yang membutuhkan penembolokan. UseRouting harus sebelum UseOutputCaching. UseCORS harus sebelum UseOutputCaching.
Penembolokan Respons Menyediakan dukungan untuk respons penembolokan. Ini mengharuskan partisipasi klien berfungsi. Gunakan penembolokan output untuk kontrol server lengkap. Sebelum komponen yang membutuhkan penembolokan. UseCORS harus sebelum UseResponseCaching. Biasanya tidak bermanfaat untuk aplikasi UI seperti Razor Pages karena browser umumnya mengatur header permintaan yang mencegah penembolokan. Manfaat penembolokan output aplikasi UI.
Dekompresi Permintaan Menyediakan dukungan untuk mendekompresi permintaan. Sebelum komponen yang membaca isi permintaan.
Pemadatan Respons Memberikan dukungan untuk memadatkan respons. Sebelum komponen yang membutuhkan pemadatan.
Pelokalan Permintaan Menyediakan dukungan pelokalan. Sebelum komponen sensitif pelokalan. Harus muncul setelah Middleware Perutean saat menggunakan RouteDataRequestCultureProvider.
Perutean Titik Akhir Mendefinisikan dan membatasi rute permintaan. Terminal untuk rute yang cocok.
SPA Menangani semua permintaan dari titik ini dalam rantai middleware dengan mengembalikan halaman default untuk Aplikasi Halaman Tunggal (SPA) Pada bagian akhir rantai, sehingga middleware lain untuk penyajian file statis, tindakan MVC, dll., diutamakan.
Sesi Menyediakan dukungan untuk mengelola sesi pengguna. Sebelum komponen yang membutuhkan Sesi.
File Statis Menyediakan dukungan untuk menyajikan file statis dan penjelajahan direktori. Terminal jika permintaan cocok dengan file.
Penulisan Ulang URL Memberikan dukungan untuk menulis kembali URL dan mengalihkan permintaan. Sebelum komponen yang menggunakan URL.
W3CLogging Menghasilkan log akses server dalam Format File Log yang Diperluas W3C. Pada awal alur middleware.
WebSocket Mengaktifkan protokol WebSocket. Sebelum komponen yang diperlukan untuk menerima permintaan WebSocket.

Sumber Daya Tambahan:

Oleh Rick Anderson dan Steve Smith

Middleware adalah perangkat lunak yang dirakit menjadi alur aplikasi untuk menangani permintaan dan respons. Setiap komponen:

  • Memilih apakah akan meneruskan permintaan ke komponen berikutnya dalam alur.
  • Dapat melakukan pekerjaan sebelum dan sesudah komponen berikutnya dalam alur.

Delegasi permintaan digunakan untuk membangun alur permintaan. Delegasi permintaan menangani setiap permintaan HTTP.

Delegasi permintaan dikonfigurasi menggunakan metode ekstensi Run, Map, dan Use. Delegasi permintaan individu dapat ditentukan dalam baris sebagai metode anonim (disebut middleware dalam baris), atau dapat didefinisikan dalam kelas yang dapat digunakan kembali. Kelas yang dapat digunakan kembali dan metode anonim dalam baris ini adalah middleware, yang juga disebut sebagai komponen middleware. Setiap komponen middleware dalam alur permintaan bertanggung jawab untuk memanggil komponen berikutnya dalam alur atau mengakhiri alur. Saat middleware diakhiri, ini disebut middleware terminal karena ini mencegah middleware berikutnya untuk memproses permintaan.

Migrasikan pengatur dan modul HTTP ke middleware ASP.NET Core menjelaskan perbedaan antara alur permintaan di ASP.NET Core dan ASP.NET 4.x dan menyediakan sampel middleware tambahan.

Analisis kode middleware

ASP.NET Core menyertakan banyak penganalisis platform kompiler yang memeriksa kualitas kode aplikasi. Untuk informasi lebih lanjut, lihat Analisis kode di aplikasi ASP.NET Core

Membuat saluran middleware dengan WebApplication

Alur permintaan ASP.NET Core terdiri dari urutan delegasi permintaan, yang dipanggil satu demi satu. Diagram berikut menunjukkan konsep tersebut. Utas eksekusi mengikuti panah hitam.

Pola pemrosesan permintaan yang menunjukkan permintaan tiba, pemrosesan melalui tiga middleware, dan respons meninggalkan aplikasi. Setiap middleware menjalankan logikanya dan menyerahkan permintaan ke middleware berikutnya pada pernyataan next(). Setelah middleware ketiga memproses permintaan, permintaan melewati kembali dua middleware sebelumnya dalam urutan terbalik untuk pemrosesan tambahan setelah pernyataan next() sebelum meninggalkan aplikasi sebagai respons terhadap klien.

Setiap delegasi dapat melakukan operasi sebelum dan sesudah delegasi berikutnya. Delegasi penanganan pengecualian harus dipanggil di awal alur, sehingga mereka dapat menangkap pengecualian yang terjadi di tahap selanjutnya dari alur.

Aplikasi ASP.NET Core yang paling sederhana menyiapkan delegasi permintaan tunggal yang menangani semua permintaan. Kasus ini tidak termasuk alur permintaan yang sebenarnya. Sebagai gantinya, satu fungsi anonim dipanggil sebagai respons terhadap setiap permintaan HTTP.

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

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

app.Run();

Tautkan beberapa delegasi permintaan bersama dengan Use. Parameter next mewakili delegasi berikutnya dalam alur. Anda dapat mengakhiri alur dengan tidak memanggil parameter next. Anda biasanya dapat melakukan tindakan sebelum dan sesudah delegasi next, seperti yang diperlihatkan contoh berikut:

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

app.Use(async (context, next) =>
{
    // Do work that can 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();

Saat delegasi tidak meneruskan permintaan ke delegasi berikutnya, hal itu disebut mengakhiri alur permintaan. Memutus hubungan sering kali diperlukan karena akan menghindari pekerjaan yang tidak perlu. Misalnya, Middleware File Statis dapat bertindak sebagai middleware terminal dengan memproses permintaan untuk file statis dan mengakhiri sisa alur. Middleware yang ditambahkan ke alur sebelum middleware yang menghentikan pemrosesan lebih lanjut masih memproses kode setelah pernyataan next.Invoke-nya. Namun, lihat peringatan berikut tentang mencoba menulis ke respons yang telah dikirim.

Peringatan

Jangan panggil next.Invoke setelah respons dikirim ke klien. Perubahan ke HttpResponse setelah respons dimulai akan memunculkan pengecualian. Misalnya, mengatur header dan kode status akan memunculkan pengecualian. Menulis ke isi respons setelah memanggil next:

  • Dapat menyebabkan pelanggaran protokol. Misalnya, menulis lebih dari Content-Length yang dinyatakan.
  • Dapat merusak format isi. Misalnya, menulis catatan kaki HTML ke file CSS.

HasStarted adalah petunjuk yang berguna untuk menunjukkan apakah header telah dikirim atau isi telah ditulis.

Delegasi Run tidak menerima parameter next. Delegasi Run pertama selalu terminal dan mengakhiri alur. Run adalah sebuah konvensi. Beberapa komponen middleware dapat mengekspos metode Run[Middleware] yang berjalan di akhir alur:

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

app.Use(async (context, next) =>
{
    // Do work that can 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();

Jika Anda ingin melihat komentar kode yang diterjemahkan ke bahasa selain bahasa Inggris, beri tahu kami dalam masalah diskusi GitHub ini.

Dalam contoh sebelumnya, delegasi Run menulis "Hello from 2nd delegate." ke respons dan kemudian mengakhiri alur. Jika delegasi Use atau Run lain ditambahkan setelah delegasi Run, delegasi tersebut tidak dipanggil.

Lebih memilih overload app.Use yang mengharuskan penerusan konteks ke berikutnya

Metode ekstensi app.Use yang tidak dialokasikan:

  • Mengharuskan penerusan konteks ke next.
  • Menyimpan dua alokasi per permintaan internal yang diperlukan saat menggunakan overload lainnya.

Untuk informasi lebih lanjut, lihat masalah GitHub ini.

Urutan middleware

Diagram berikut menunjukkan alur pemrosesan permintaan lengkap untuk aplikasi ASP.NET Core MVC dan Razor Pages. Anda dapat melihat bagaimana, dalam aplikasi pada umumnya, middleware yang ada diurutkan dan di mana middleware kustom ditambahkan. Anda memiliki kendali penuh dalam bagaimana cara mengurutkan kembali middleware yang ada atau menyuntikkan middleware kustom baru yang diperlukan untuk skenario Anda.

Alur middleware ASP.NET Core

Middleware Titik akhir dalam diagram sebelumnya menjalankan alur filter untuk jenis aplikasi yang sesuai—MVC atau Razor Pages.

Middleware Perutean dalam diagram sebelumnya ditunjukkan mengikuti File Statis. Ini adalah urutan yang diimplementasikan oleh template proyek dengan memanggil app.UseRouting secara eksplisit. Jika Anda tidak memanggil app.UseRouting, middleware Perutean berjalan di awal alur secara default. Untuk informasi selengkapnya, lihat Perutean.

Alur filter ASP.NET Core

Urutan penambahan komponen middleware dalam file Program.cs menentukan urutan komponen middleware dipanggil pada permintaan dan urutan terbalik untuk respons. Urutan ini penting untuk keamanan, performa, dan fungsionalitas.

Kode yang disorot berikut ini di Program.cs menambahkan komponen middleware terkait keamanan dalam urutan yang disarankan pada umumnya:

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();

Dalam kode sebelumnya:

  • Middleware yang tidak ditambahkan saat membuat aplikasi web baru dengan akun pengguna individu dikomentari.
  • Tidak setiap middleware muncul dalam urutan yang persis seperti ini, tetapi banyak yang demikian. Misalnya:
    • UseCors, UseAuthentication, dan UseAuthorization harus muncul dalam urutan yang ditampilkan.
    • UseCors saat ini harus muncul sebelum UseResponseCaching. Persyaratan ini dijelaskan dalam Masalah GitHub dotnet/aspnetcore #23218.
    • UseRequestLocalization harus muncul sebelum middleware apa pun yang mungkin memeriksa budaya permintaan (misalnya, app.UseMvcWithDefaultRoute()).

Dalam beberapa skenario, middleware memiliki urutan yang berbeda. Misalnya, pengurutan penembolokan dan pemadatan adalah skenario khusus, dan ada beberapa pengurutan yang valid. Contohnya:

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

Dengan kode sebelumnya, penggunaan CPU dapat dikurangi dengan melakukan penembolokan pada respons yang dipadatkan, tetapi Anda mungkin akan melakukan penembolokan beberapa representasi sumber daya menggunakan algoritma pemadatan yang berbeda seperti Gzip atau Brotli.

Urutan berikut menggabungkan file statis untuk memungkinkan penembolokan file statis yang dipadatkan:

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

Kode Program.cs berikut menambahkan komponen middleware untuk skenario aplikasi umum:

  1. Penanganan pengecualian/kesalahan
    • Saat aplikasi berjalan di lingkungan Pengembangan:
      • Middleware Halaman Pengecualian Pengembang (UseDeveloperExceptionPage) melaporkan kesalahan runtime bahasa umum aplikasi.
      • Middleware Halaman Kesalahan Database (UseDatabaseErrorPage) melaporkan kesalahan runtime bahasa umum database.
    • Saat aplikasi berjalan di lingkungan Produksi:
      • Middleware Penanganan Pengecualian (UseExceptionHandler) menangkap pengecualian yang ditampilkan ke middleware berikut.
      • Middleware HTTP Strict Transport Security Protocol (HSTS) (UseHsts) menambahkan header Strict-Transport-Security.
  2. Middleware Pengalihan HTTPS (UseHttpsRedirection) mengalihkan permintaan HTTP ke HTTPS.
  3. Middleware File Statis (UseStaticFiles) mengembalikan file statis dan mengakhiri pemrosesan permintaan lebih lanjut.
  4. Middleware Kebijakan Cookie (UseCookiePolicy) menyesuaikan aplikasi dengan Peraturan Perlindungan Data Umum (GDPR) Eropa.
  5. Middleware Perutean (UseRouting) untuk merutekan permintaan.
  6. Middleware Autentikasi (UseAuthentication) mencoba mengautentikasi pengguna sebelum mereka diizinkan mengakses sumber daya yang aman.
  7. Middleware Otorisasi (UseAuthorization) memberi wewenang kepada pengguna untuk mengakses sumber daya yang aman.
  8. Middleware Sesi (UseSession) menetapkan dan mempertahankan keadaan sesi. Jika aplikasi menggunakan keadaan sesi, panggil Middleware Sesi setelah Middleware Kebijakan Cookie dan sebelum Middleware MVC.
  9. Middleware Perutean Titik Akhir (UseEndpoints dengan MapRazorPages) untuk menambahkan titik akhir Razor Pages ke alur permintaan.
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();

Dalam kode contoh sebelumnya, setiap metode ekstensi middleware diekspos pada WebApplicationBuilder melalui namespace layanan Microsoft.AspNetCore.Builder.

UseExceptionHandler adalah komponen middleware pertama yang ditambahkan ke alur. Oleh karena itu, Middleware Penanganan Pengecualian menangkap pengecualian yang terjadi di panggilan berikutnya.

Middleware File Statis dipanggil di awal alur sehingga dapat menangani permintaan dan mengakhiri tanpa melalui komponen yang tersisa. Middleware File Statis tidak menyediakan pemeriksaan otorisasi. File apa pun yang disajikan oleh Middleware File Statis, termasuk yang berada di bawah wwwroot, tersedia untuk umum. Untuk pendekatan pengamanan file statis, lihat File statis di ASP.NET Core.

Jika permintaan tidak ditangani oleh Middleware File Statis, permintaan akan diteruskan ke Middleware Autentikasi (UseAuthentication), yang melakukan autentikasi. Autentikasi tidak mengakhiri permintaan yang tidak diautentikasi. Meskipun Middleware Autentikasi mengautentikasi permintaan, otorisasi (dan penolakan) hanya terjadi setelah MVC memilih Razor Page atau pengontrol dan tindakan MVC tertentu.

Contoh berikut menunjukkan urutan middleware di mana permintaan untuk file statis ditangani oleh Middleware File Statis sebelum Middleware Pemadatan Respons. File statis tidak dipadatkan dengan urutan middleware ini. Respons Razor Pages dapat dipadatkan.

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

app.UseRouting();

app.UseResponseCompression();

app.MapRazorPages();

Untuk informasi tentang Aplikasi Halaman Tunggal, lihat panduan untuk template proyek React dan Angular.

Urutan UseCors dan UseStaticFiles

Urutan untuk memanggil UseCors dan UseStaticFiles bergantung pada aplikasi. Untuk informasi lebih lanjut, lihat Urutan UseCors dan UseStaticFiles

Urutan Middleware Header yang Diteruskan

Middleware Header yang Diteruskan harus dijalankan sebelum middleware lainnya. Urutan ini memastikan bahwa middleware yang mengandalkan informasi header yang diteruskan dapat menggunakan nilai header untuk pemrosesan. Untuk menjalankan Middleware Header yang Diteruskan setelah middleware diagnostik dan penanganan kesalahan, lihat Urutan Middleware Header yang Diteruskan.

Membuat cabang alur middleware

Ekstensi Map digunakan sebagai konvensi untuk membuat cabang alur. Map membuat cabang alur permintaan berdasarkan pencocokan jalur permintaan yang diberikan. Jika jalur permintaan dimulai dengan jalur yang diberikan, cabang akan dijalankan.

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.");
});

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");
    });
}

Tabel berikut menunjukkan permintaan dan respons dari http://localhost:1234 menggunakan kode sebelumnya.

Permintaan Respons
localhost:1234 Halo dari delegasi non-Peta.
localhost:1234/map1 Pengujian Peta 1
localhost:1234/map2 Pengujian Peta 2
localhost:1234/map3 Halo dari delegasi non-Peta.

Saat Map digunakan, segmen jalur yang cocok akan dihapus dari HttpRequest.Path dan ditambahkan ke HttpRequest.PathBase untuk setiap permintaan.

Map mendukung bersarang, misalnya:

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

Map juga dapat mencocokkan beberapa segmen sekaligus:

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.");
});

app.Run();

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

MapWhen membuat cabang alur permintaan berdasarkan hasil dari predikat yang diberikan. Semua predikat berjenis Func<HttpContext, bool> dapat digunakan untuk memetakan permintaan ke cabang baru dari alur. Dalam contoh berikut, predikat digunakan untuk mendeteksi keberadaan variabel string kueri branch:

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

app.MapWhen(context => context.Request.Query.ContainsKey("branch"), HandleBranch);

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

app.Run();

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

Tabel berikut menunjukkan permintaan dan respons dari http://localhost:1234 menggunakan kode sebelumnya:

Permintaan Respons
localhost:1234 Hello from non-Map delegate.
localhost:1234/?branch=main Branch used = main

UseWhen juga membuat cabang alur permintaan berdasarkan hasil dari predikat yang diberikan. Tidak seperti MapWhen, cabang ini digabungkan kembali ke alur utama jika tidak diakhiri atau berisi middleware terminal:

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.");
});

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.
    });
}

Dalam contoh sebelumnya, respons Hello from non-Map delegate. ditulis untuk semua permintaan. Jika permintaan menyertakan branch variabel string kueri, nilainya dicatat sebelum alur utama bergabung kembali.

Middleware bawaan

ASP.NET Core dikirimkan dengan komponen middleware berikut. Kolom Urutan memberikan catatan tentang penempatan middleware di alur pemrosesan permintaan dan dalam kondisi apa middleware dapat menghentikan pemrosesan permintaan. Saat middleware mengakhiri alur pemrosesan permintaan dan mencegah middleware downstream berikutnya memproses permintaan, itu disebut middleware terminal. Untuk informasi selengkapnya tentang sirkuit pendek, lihat bagian Membuat alur middleware dengan WebApplication .

Middleware Deskripsi Pesanan
Autentikasi Menyediakan dukungan autentikasi. Sebelum HttpContext.User diperlukan. Terminal untuk panggilan balik OAuth.
Otorisasi Menyediakan dukungan otorisasi. Segera setelah Middleware Autentikasi.
Kebijakan Cookie Melacak persetujuan dari pengguna untuk menyimpan informasi pribadi dan menerapkan standar minimum untuk bidang cookie, seperti secure dan SameSite. Sebelum middleware yang mengeluarkan cookie. Contoh: Autentikasi, Sesi, MVC (TempData).
CORS Mengonfigurasi Cross-Origin Resource Sharing. Sebelum komponen yang menggunakan CORS. UseCors saat ini harus sebelum UseResponseCaching karena bug ini.
DeveloperExceptionPage Menghasilkan halaman dengan informasi kesalahan yang dimaksudkan untuk digunakan hanya di lingkungan Pengembangan. Sebelum komponen yang menghasilkan kesalahan. Template proyek secara otomatis mendaftarkan middleware ini sebagai middleware pertama dalam alur saat lingkungan sedang dalam Pengembangan.
Diagnostik Beberapa middleware terpisah yang menyediakan halaman pengecualian pengembang, penanganan pengecualian, halaman kode status, dan halaman web default untuk aplikasi baru. Sebelum komponen yang menghasilkan kesalahan. Terminal untuk pengecualian atau menyajikan halaman web default untuk aplikasi baru.
Header yang Diteruskan Meneruskan header yang diproksi ke permintaan saat ini. Sebelum komponen yang menggunakan bidang yang diperbarui. Contoh: skema, host, IP klien, metode.
Pemeriksaan Kesehatan Memeriksa kesehatan aplikasi ASP.NET Core dan dependensinya, seperti memeriksa ketersediaan database. Terminal jika permintaan cocok dengan titik akhir pemeriksaan kesehatan.
Propagasi Header Mempropagasi header HTTP dari permintaan masuk ke permintaan Klien HTTP keluar.
Pengelogan HTTP Mencatat Permintaan dan Respons HTTP. Pada awal alur middleware.
Penimpaan Metode HTTP Mengizinkan permintaan POST yang masuk untuk menimpa metode. Sebelum komponen yang menggunakan metode yang diperbarui.
Pengalihan HTTPS Mengalihkan semua permintaan HTTP ke HTTPS. Sebelum komponen yang menggunakan URL.
HTTP Strict Transport Security (HSTS) Middleware peningkatan keamanan yang menambahkan header respons khusus. Sebelum respons dikirim dan setelah komponen yang mengubah permintaan. Contoh: Header yang Diteruskan, Penulisan Ulang URL.
MVC Memproses permintaan dengan MVC/Razor Pages. Terminal jika permintaan cocok dengan rute.
OWIN Interop dengan aplikasi, server, dan middleware berbasis OWIN. Terminal jika Middleware OWIN sepenuhnya memproses permintaan.
Dekompresi Permintaan Menyediakan dukungan untuk mendekompresi permintaan. Sebelum komponen yang membaca isi permintaan.
Penembolokan Respons Menyediakan dukungan untuk respons penembolokan. Sebelum komponen yang membutuhkan penembolokan. UseCORS harus sebelum UseResponseCaching.
Pemadatan Respons Memberikan dukungan untuk memadatkan respons. Sebelum komponen yang membutuhkan pemadatan.
Pelokalan Permintaan Menyediakan dukungan pelokalan. Sebelum komponen sensitif pelokalan. Harus muncul setelah Middleware Perutean saat menggunakan RouteDataRequestCultureProvider.
Perutean Titik Akhir Mendefinisikan dan membatasi rute permintaan. Terminal untuk rute yang cocok.
SPA Menangani semua permintaan dari titik ini dalam rantai middleware dengan mengembalikan halaman default untuk Aplikasi Halaman Tunggal (SPA) Pada bagian akhir rantai, sehingga middleware lain untuk penyajian file statis, tindakan MVC, dll., diutamakan.
Sesi Menyediakan dukungan untuk mengelola sesi pengguna. Sebelum komponen yang membutuhkan Sesi.
File Statis Menyediakan dukungan untuk menyajikan file statis dan penjelajahan direktori. Terminal jika permintaan cocok dengan file.
Penulisan Ulang URL Memberikan dukungan untuk menulis kembali URL dan mengalihkan permintaan. Sebelum komponen yang menggunakan URL.
W3CLogging Menghasilkan log akses server dalam Format File Log yang Diperluas W3C. Pada awal alur middleware.
WebSocket Mengaktifkan protokol WebSocket. Sebelum komponen yang diperlukan untuk menerima permintaan WebSocket.

Sumber Daya Tambahan:

Oleh Rick Anderson dan Steve Smith

Middleware adalah perangkat lunak yang dirakit menjadi alur aplikasi untuk menangani permintaan dan respons. Setiap komponen:

  • Memilih apakah akan meneruskan permintaan ke komponen berikutnya dalam alur.
  • Dapat melakukan pekerjaan sebelum dan sesudah komponen berikutnya dalam alur.

Delegasi permintaan digunakan untuk membangun alur permintaan. Delegasi permintaan menangani setiap permintaan HTTP.

Delegasi permintaan dikonfigurasi menggunakan metode ekstensi Run, Map, dan Use. Delegasi permintaan individu dapat ditentukan dalam baris sebagai metode anonim (disebut middleware dalam baris), atau dapat didefinisikan dalam kelas yang dapat digunakan kembali. Kelas yang dapat digunakan kembali dan metode anonim dalam baris ini adalah middleware, yang juga disebut sebagai komponen middleware. Setiap komponen middleware dalam alur permintaan bertanggung jawab untuk memanggil komponen berikutnya dalam alur atau mengakhiri alur. Saat middleware diakhiri, ini disebut middleware terminal karena ini mencegah middleware berikutnya untuk memproses permintaan.

Migrasikan pengatur dan modul HTTP ke middleware ASP.NET Core menjelaskan perbedaan antara alur permintaan di ASP.NET Core dan ASP.NET 4.x dan menyediakan sampel middleware tambahan.

Membuat alur middleware dengan IApplicationBuilder

Alur permintaan ASP.NET Core terdiri dari urutan delegasi permintaan, yang dipanggil satu demi satu. Diagram berikut menunjukkan konsep tersebut. Utas eksekusi mengikuti panah hitam.

Pola pemrosesan permintaan yang menunjukkan permintaan tiba, pemrosesan melalui tiga middleware, dan respons meninggalkan aplikasi. Setiap middleware menjalankan logikanya dan menyerahkan permintaan ke middleware berikutnya pada pernyataan next(). Setelah middleware ketiga memproses permintaan, permintaan melewati kembali dua middleware sebelumnya dalam urutan terbalik untuk pemrosesan tambahan setelah pernyataan next() sebelum meninggalkan aplikasi sebagai respons terhadap klien.

Setiap delegasi dapat melakukan operasi sebelum dan sesudah delegasi berikutnya. Delegasi penanganan pengecualian harus dipanggil di awal alur, sehingga mereka dapat menangkap pengecualian yang terjadi di tahap selanjutnya dari alur.

Aplikasi ASP.NET Core yang paling sederhana menyiapkan delegasi permintaan tunggal yang menangani semua permintaan. Kasus ini tidak termasuk alur permintaan yang sebenarnya. Sebagai gantinya, satu fungsi anonim dipanggil sebagai respons terhadap setiap permintaan HTTP.

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

Tautkan beberapa delegasi permintaan bersama dengan Use. Parameter next mewakili delegasi berikutnya dalam alur. Anda dapat mengakhiri alur dengan tidak memanggil parameter berikutnya. Anda biasanya dapat melakukan tindakan sebelum dan sesudah delegasi berikutnya, seperti yang diperlihatkan contoh berikut:

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.");
        });
    }
}

Saat delegasi tidak meneruskan permintaan ke delegasi berikutnya, hal itu disebut mengakhiri alur permintaan. Memutus hubungan sering kali diperlukan karena akan menghindari pekerjaan yang tidak perlu. Misalnya, Middleware File Statis dapat bertindak sebagai middleware terminal dengan memproses permintaan untuk file statis dan mengakhiri sisa alur. Middleware yang ditambahkan ke alur sebelum middleware yang menghentikan pemrosesan lebih lanjut masih memproses kode setelah pernyataan next.Invoke-nya. Namun, lihat peringatan berikut tentang mencoba menulis ke respons yang telah dikirim.

Peringatan

Jangan panggil next.Invoke setelah respons dikirim ke klien. Perubahan ke HttpResponse setelah respons dimulai akan memunculkan pengecualian. Misalnya, mengatur header dan kode status akan memunculkan pengecualian. Menulis ke isi respons setelah memanggil next:

  • Dapat menyebabkan pelanggaran protokol. Misalnya, menulis lebih dari Content-Length yang dinyatakan.
  • Dapat merusak format isi. Misalnya, menulis catatan kaki HTML ke file CSS.

HasStarted adalah petunjuk yang berguna untuk menunjukkan apakah header telah dikirim atau isi telah ditulis.

Delegasi Run tidak menerima parameter next. Delegasi Run pertama selalu terminal dan mengakhiri alur. Run adalah sebuah konvensi. Beberapa komponen middleware dapat mengekspos metode Run[Middleware] yang berjalan di akhir alur:

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.");
        });
    }
}

Jika Anda ingin melihat komentar kode yang diterjemahkan ke bahasa selain bahasa Inggris, beri tahu kami dalam masalah diskusi GitHub ini.

Dalam contoh sebelumnya, delegasi Run menulis "Hello from 2nd delegate." ke respons dan kemudian mengakhiri alur. Jika delegasi Use atau Run lain ditambahkan setelah delegasi Run, delegasi tersebut tidak dipanggil.

Urutan middleware

Diagram berikut menunjukkan alur pemrosesan permintaan lengkap untuk aplikasi ASP.NET Core MVC dan Razor Pages. Anda dapat melihat bagaimana, dalam aplikasi pada umumnya, middleware yang ada diurutkan dan di mana middleware kustom ditambahkan. Anda memiliki kendali penuh dalam bagaimana cara mengurutkan kembali middleware yang ada atau menyuntikkan middleware kustom baru yang diperlukan untuk skenario Anda.

Alur middleware ASP.NET Core

Middleware Titik akhir dalam diagram sebelumnya menjalankan alur filter untuk jenis aplikasi yang sesuai—MVC atau Razor Pages.

Alur filter ASP.NET Core

Urutan komponen middleware yang ditambahkan dalam metode Startup.Configure menentukan urutan pemanggilan komponen middleware pada permintaan dan urutan terbalik untuk respons. Urutan ini penting untuk keamanan, performa, dan fungsionalitas.

Metode Startup.Configure berikut menambahkan komponen middleware terkait keamanan dalam urutan yang disarankan pada umumnya:

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?}");
    });
}

Dalam kode sebelumnya:

  • Middleware yang tidak ditambahkan saat membuat aplikasi web baru dengan akun pengguna individu dikomentari.
  • Tidak setiap middleware muncul dalam urutan yang persis seperti ini, tetapi banyak yang demikian. Misalnya:
    • UseCors, UseAuthentication, dan UseAuthorization harus muncul dalam urutan yang ditampilkan.
    • UseCors saat ini harus muncul sebelum UseResponseCaching karena bug ini.
    • UseRequestLocalization harus muncul sebelum middleware apa pun yang mungkin memeriksa budaya permintaan (misalnya, app.UseMvcWithDefaultRoute()).

Dalam beberapa skenario, middleware memiliki urutan yang berbeda. Misalnya, pengurutan penembolokan dan pemadatan adalah skenario khusus, dan ada beberapa pengurutan yang valid. Contohnya:

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

Dengan kode sebelumnya, CPU dapat disimpan dengan melakukan penembolokan pada respons yang dipadatkan, tetapi Anda mungkin akan melakukan penembolokan beberapa representasi sumber daya menggunakan algoritma pemadatan yang berbeda seperti Gzip atau Brotli.

Urutan berikut menggabungkan file statis untuk memungkinkan penembolokan file statis yang dipadatkan:

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

Metode Startup.Configure berikut menambahkan komponen middleware untuk skenario aplikasi umum:

  1. Penanganan pengecualian/kesalahan
    • Saat aplikasi berjalan di lingkungan Pengembangan:
      • Middleware Halaman Pengecualian Pengembang (UseDeveloperExceptionPage) melaporkan kesalahan runtime bahasa umum aplikasi.
      • Middleware Halaman Kesalahan Database melaporkan kesalahan runtime bahasa umum database.
    • Saat aplikasi berjalan di lingkungan Produksi:
      • Middleware Penanganan Pengecualian (UseExceptionHandler) menangkap pengecualian yang ditampilkan ke middleware berikut.
      • Middleware HTTP Strict Transport Security Protocol (HSTS) (UseHsts) menambahkan header Strict-Transport-Security.
  2. Middleware Pengalihan HTTPS (UseHttpsRedirection) mengalihkan permintaan HTTP ke HTTPS.
  3. Middleware File Statis (UseStaticFiles) mengembalikan file statis dan mengakhiri pemrosesan permintaan lebih lanjut.
  4. Middleware Kebijakan Cookie (UseCookiePolicy) menyesuaikan aplikasi dengan Peraturan Perlindungan Data Umum (GDPR) Eropa.
  5. Middleware Perutean (UseRouting) untuk merutekan permintaan.
  6. Middleware Autentikasi (UseAuthentication) mencoba mengautentikasi pengguna sebelum mereka diizinkan mengakses sumber daya yang aman.
  7. Middleware Otorisasi (UseAuthorization) memberi wewenang kepada pengguna untuk mengakses sumber daya yang aman.
  8. Middleware Sesi (UseSession) menetapkan dan mempertahankan keadaan sesi. Jika aplikasi menggunakan keadaan sesi, panggil Middleware Sesi setelah Middleware Kebijakan Cookie dan sebelum Middleware MVC.
  9. Middleware Perutean Titik Akhir (UseEndpoints dengan MapRazorPages) untuk menambahkan titik akhir Razor Pages ke alur permintaan.
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();
    });
}

Dalam kode contoh sebelumnya, setiap metode ekstensi middleware diekspos pada IApplicationBuilder melalui namespace layanan Microsoft.AspNetCore.Builder.

UseExceptionHandler adalah komponen middleware pertama yang ditambahkan ke alur. Oleh karena itu, Middleware Penanganan Pengecualian menangkap pengecualian yang terjadi di panggilan berikutnya.

Middleware File Statis dipanggil di awal alur sehingga dapat menangani permintaan dan mengakhiri tanpa melalui komponen yang tersisa. Middleware File Statis tidak menyediakan pemeriksaan otorisasi. File apa pun yang disajikan oleh Middleware File Statis, termasuk yang berada di bawah wwwroot, tersedia untuk umum. Untuk pendekatan pengamanan file statis, lihat File statis di ASP.NET Core.

Jika permintaan tidak ditangani oleh Middleware File Statis, permintaan akan diteruskan ke Middleware Autentikasi (UseAuthentication), yang melakukan autentikasi. Autentikasi tidak mengakhiri permintaan yang tidak diautentikasi. Meskipun Middleware Autentikasi mengautentikasi permintaan, otorisasi (dan penolakan) hanya terjadi setelah MVC memilih Razor Page atau pengontrol dan tindakan MVC tertentu.

Contoh berikut menunjukkan urutan middleware di mana permintaan untuk file statis ditangani oleh Middleware File Statis sebelum Middleware Pemadatan Respons. File statis tidak dipadatkan dengan urutan middleware ini. Respons Razor Pages dapat dipadatkan.

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();
    });
}

Untuk Aplikasi Halaman Tunggal (SPA), UseSpaStaticFiles middleware SPA biasanya berada di urutan terakhir dalam alur middleware. Middleware SPA menjadi yang terakhir:

  • Untuk mengizinkan semua middleware lain untuk merespons permintaan yang cocok terlebih dahulu.
  • Untuk mengizinkan SPA dengan perutean sisi klien berjalan untuk semua rute yang tidak dikenali oleh aplikasi server.

Guna mengetahui detail lebih lanjut tentang SPA, lihat panduan untuk template proyek React dan Angular.

Urutan Middleware Header yang Diteruskan

Middleware Header yang Diteruskan harus dijalankan sebelum middleware lainnya. Urutan ini memastikan bahwa middleware yang mengandalkan informasi header yang diteruskan dapat menggunakan nilai header untuk pemrosesan. Untuk menjalankan Middleware Header yang Diteruskan setelah middleware diagnostik dan penanganan kesalahan, lihat Urutan Middleware Header yang Diteruskan.

Membuat cabang alur middleware

Ekstensi Map digunakan sebagai konvensi untuk membuat cabang alur. Map membuat cabang alur permintaan berdasarkan pencocokan jalur permintaan yang diberikan. Jika jalur permintaan dimulai dengan jalur yang diberikan, cabang akan dijalankan.

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.");
        });
    }
}

Tabel berikut menunjukkan permintaan dan respons dari http://localhost:1234 menggunakan kode sebelumnya.

Permintaan Respons
localhost:1234 Halo dari delegasi non-Peta.
localhost:1234/map1 Pengujian Peta 1
localhost:1234/map2 Pengujian Peta 2
localhost:1234/map3 Halo dari delegasi non-Peta.

Saat Map digunakan, segmen jalur yang cocok akan dihapus dari HttpRequest.Path dan ditambahkan ke HttpRequest.PathBase untuk setiap permintaan.

Map mendukung bersarang, misalnya:

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

Map juga dapat mencocokkan beberapa segmen sekaligus:

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 membuat cabang alur permintaan berdasarkan hasil dari predikat yang diberikan. Semua predikat berjenis Func<HttpContext, bool> dapat digunakan untuk memetakan permintaan ke cabang baru dari alur. Dalam contoh berikut, predikat digunakan untuk mendeteksi keberadaan variabel string kueri 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.");
        });
    }
}

Tabel berikut menunjukkan permintaan dan respons dari http://localhost:1234 menggunakan kode sebelumnya:

Permintaan Respons
localhost:1234 Halo dari delegasi non-Peta.
localhost:1234/?branch=main Cabang yang digunakan = utama

UseWhen juga membuat cabang alur permintaan berdasarkan hasil dari predikat yang diberikan. Tidak seperti MapWhen, cabang ini digabungkan kembali ke alur utama jika tidak diakhiri atau berisi middleware terminal:

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.");
        });
    }
}

Dalam contoh sebelumnya, respons "Halo dari alur utama." ditulis untuk semua permintaan. Jika permintaan menyertakan branch variabel string kueri, nilainya dicatat sebelum alur utama bergabung kembali.

Middleware bawaan

ASP.NET Core dikirimkan dengan komponen middleware berikut. Kolom Urutan memberikan catatan tentang penempatan middleware di alur pemrosesan permintaan dan dalam kondisi apa middleware dapat menghentikan pemrosesan permintaan. Saat middleware mengakhiri alur pemrosesan permintaan dan mencegah middleware downstream berikutnya memproses permintaan, itu disebut middleware terminal. Untuk informasi lebih lanjut tentang mengakhiri alur, lihat bagian Membuat alur middleware dengan IApplicationBuilder.

Middleware Deskripsi Pesanan
Autentikasi Menyediakan dukungan autentikasi. Sebelum HttpContext.User diperlukan. Terminal untuk panggilan balik OAuth.
Otorisasi Menyediakan dukungan otorisasi. Segera setelah Middleware Autentikasi.
Kebijakan Cookie Melacak persetujuan dari pengguna untuk menyimpan informasi pribadi dan menerapkan standar minimum untuk bidang cookie, seperti secure dan SameSite. Sebelum middleware yang mengeluarkan cookie. Contoh: Autentikasi, Sesi, MVC (TempData).
CORS Mengonfigurasi Cross-Origin Resource Sharing. Sebelum komponen yang menggunakan CORS. UseCors saat ini harus sebelum UseResponseCaching karena bug ini.
Diagnostik Beberapa middleware terpisah yang menyediakan halaman pengecualian pengembang, penanganan pengecualian, halaman kode status, dan halaman web default untuk aplikasi baru. Sebelum komponen yang menghasilkan kesalahan. Terminal untuk pengecualian atau menyajikan halaman web default untuk aplikasi baru.
Header yang Diteruskan Meneruskan header yang diproksi ke permintaan saat ini. Sebelum komponen yang menggunakan bidang yang diperbarui. Contoh: skema, host, IP klien, metode.
Pemeriksaan Kesehatan Memeriksa kesehatan aplikasi ASP.NET Core dan dependensinya, seperti memeriksa ketersediaan database. Terminal jika permintaan cocok dengan titik akhir pemeriksaan kesehatan.
Propagasi Header Mempropagasi header HTTP dari permintaan masuk ke permintaan Klien HTTP keluar.
Penimpaan Metode HTTP Mengizinkan permintaan POST yang masuk untuk menimpa metode. Sebelum komponen yang menggunakan metode yang diperbarui.
Pengalihan HTTPS Mengalihkan semua permintaan HTTP ke HTTPS. Sebelum komponen yang menggunakan URL.
HTTP Strict Transport Security (HSTS) Middleware peningkatan keamanan yang menambahkan header respons khusus. Sebelum respons dikirim dan setelah komponen yang mengubah permintaan. Contoh: Header yang Diteruskan, Penulisan Ulang URL.
MVC Memproses permintaan dengan MVC/Razor Pages. Terminal jika permintaan cocok dengan rute.
OWIN Interop dengan aplikasi, server, dan middleware berbasis OWIN. Terminal jika Middleware OWIN sepenuhnya memproses permintaan.
Penembolokan Respons Menyediakan dukungan untuk respons penembolokan. Sebelum komponen yang membutuhkan penembolokan. UseCORS harus sebelum UseResponseCaching.
Pemadatan Respons Memberikan dukungan untuk memadatkan respons. Sebelum komponen yang membutuhkan pemadatan.
Pelokalan Permintaan Menyediakan dukungan pelokalan. Sebelum komponen sensitif pelokalan. Harus muncul setelah Middleware Perutean saat menggunakan RouteDataRequestCultureProvider.
Perutean Titik Akhir Mendefinisikan dan membatasi rute permintaan. Terminal untuk rute yang cocok.
SPA Menangani semua permintaan dari titik ini dalam rantai middleware dengan mengembalikan halaman default untuk Aplikasi Halaman Tunggal (SPA) Pada bagian akhir rantai, sehingga middleware lain untuk penyajian file statis, tindakan MVC, dll., diutamakan.
Sesi Menyediakan dukungan untuk mengelola sesi pengguna. Sebelum komponen yang membutuhkan Sesi.
File Statis Menyediakan dukungan untuk menyajikan file statis dan penjelajahan direktori. Terminal jika permintaan cocok dengan file.
Penulisan Ulang URL Memberikan dukungan untuk menulis kembali URL dan mengalihkan permintaan. Sebelum komponen yang menggunakan URL.
WebSocket Mengaktifkan protokol WebSocket. Sebelum komponen yang diperlukan untuk menerima permintaan WebSocket.

Sumber Daya Tambahan: