ASP.NET Core のミドルウェアASP.NET Core Middleware

作成者: Rick AndersonSteve SmithBy Rick Anderson and Steve Smith

ミドルウェアとは、要求と応答を処理するために、アプリのパイプラインに組み込まれたソフトウェアです。Middleware is software that's assembled into an app pipeline to handle requests and responses. 各コンポーネントで次の処理を実行します。Each component:

  • 要求をパイプライン内の次のコンポーネントに渡すかどうかを選択します。Chooses whether to pass the request to the next component in the pipeline.
  • パイプラインの次のコンポーネントの前または後に作業を実行できます。Can perform work before and after the next component in the pipeline.

要求デリゲートは、要求パイプラインの構築に使用されます。Request delegates are used to build the request pipeline. 要求デリゲートは、各 HTTP 要求を処理します。The request delegates handle each HTTP request.

要求デリゲートは、RunMapUse の各拡張メソッドを使って構成されます。Request delegates are configured using Run, Map, and Use extension methods. 個々の要求デリゲートは、匿名メソッドとしてインラインで指定するか (インライン ミドルウェアと呼ばれます)、または再利用可能なクラスで定義することができます。An individual request delegate can be specified in-line as an anonymous method (called in-line middleware), or it can be defined in a reusable class. これらの再利用可能なクラスとインラインの匿名メソッドは、"ミドルウェア" です。"ミドルウェア コンポーネント" とも呼ばれます。These reusable classes and in-line anonymous methods are middleware, also called middleware components. 要求パイプライン内の各ミドルウェア コンポーネントは、パイプラインの次のコンポーネントを呼び出すか、パイプラインをショートさせます。Each middleware component in the request pipeline is responsible for invoking the next component in the pipeline or short-circuiting the pipeline. ショートサーキットしたミドルウェアは "ターミナル ミドルウェア" と呼ばれます。これによってさらなるミドルウェアによる要求の処理が回避されるためです。When a middleware short-circuits, it's called a terminal middleware because it prevents further middleware from processing the request.

HTTP ハンドラーとモジュールを ASP.NET Core ミドルウェアに移行する では、ASP.NET Core と ASP.NET 4.x の要求パイプラインの違いについて説明し、その他のミドルウェア サンプルが提供されています。HTTP ハンドラーとモジュールを ASP.NET Core ミドルウェアに移行する explains the difference between request pipelines in ASP.NET Core and ASP.NET 4.x and provides additional middleware samples.

IApplicationBuilder を使用したミドルウェア パイプラインの作成Create a middleware pipeline with IApplicationBuilder

ASP.NET Core 要求パイプラインは、順番に呼び出される一連の要求デリゲートで構成されています。The ASP.NET Core request pipeline consists of a sequence of request delegates, called one after the other. 次の図は、その概念を示しています。The following diagram demonstrates the concept. 実行のスレッドは黒い矢印をたどります。The thread of execution follows the black arrows.

要求の到着、3 つのミドルウェアによる処理、アプリからの応答の送信を示す要求処理パターン。

各デリゲートは、次のデリゲートの前と後に操作を実行できます。Each delegate can perform operations before and after the next delegate. 例外処理デリゲートは、パイプラインの後のステージで発生する例外をキャッチできるように、パイプラインの早い段階で呼び出される必要があります。Exception-handling delegates should be called early in the pipeline, so they can catch exceptions that occur in later stages of the pipeline.

考えられる最も簡単な ASP.NET Core アプリは、1 つの要求デリゲートを設定してすべての要求を処理するものです。The simplest possible ASP.NET Core app sets up a single request delegate that handles all requests. この場合、実際の要求パイプラインは含まれません。This case doesn't include an actual request pipeline. 代わりに、すべての HTTP 要求に対応して単一の匿名関数が呼び出されます。Instead, a single anonymous function is called in response to every HTTP request.

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

複数の要求デリゲートを Use と一緒にチェーンします。Chain multiple request delegates together with Use. next パラメーターは、パイプラインの次のデリゲートを表しますThe next parameter represents the next delegate in the pipeline. next パラメーターを "呼び出さない" ことで、パイプラインをショートさせることができます。You can short-circuit the pipeline by not calling the next parameter. 次の例で示すように、通常は、次のデリゲートの前と後の両方でアクションを実行できます。You can typically perform actions both before and after the next delegate, as the following example demonstrates:

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

デリゲートが次のデリゲートに要求を渡さない場合、これは "要求パイプラインのショートサーキット" と呼ばれます。When a delegate doesn't pass a request to the next delegate, it's called short-circuiting the request pipeline. 不要な処理を回避するために、ショートさせることが望ましい場合がよくあります。Short-circuiting is often desirable because it avoids unnecessary work. たとえば、静的ファイル ミドルウェアは、静的ファイルの要求を処理して残りのパイプラインをショートサーキットすることにより、"ターミナル ミドルウェア" として動作させることができます。For example, Static File Middleware can act as a terminal middleware by processing a request for a static file and short-circuiting the rest of the pipeline. 後続の処理を終了させるミドルウェアの前にパイプラインに追加されたミドルウェアでは、その next.Invoke ステートメントの後も引き続きコードが処理されます。Middleware added to the pipeline before the middleware that terminates further processing still processes code after their next.Invoke statements. ただし、既に送信された応答に対する書き込みの試行については、次の警告を参照してください。However, see the following warning about attempting to write to a response that has already been sent.

警告

応答がクライアントに送信された後に、next.Invoke を呼び出さないでください。Don't call next.Invoke after the response has been sent to the client. 応答が開始した後で HttpResponse を変更すると、例外がスローされます。Changes to HttpResponse after the response has started throw an exception. たとえば、ヘッダーや状態コードを設定すると、例外がスローされますFor example, setting headers and a status code throw an exception. next を呼び出した後で応答本文に書き込むと、次のようになります。Writing to the response body after calling next:

  • プロトコル違反が発生する可能性があります。May cause a protocol violation. たとえば、示されている Content-Length より多くを書き込んだ場合。For example, writing more than the stated Content-Length.
  • 本文の形式が破損する可能性があります。May corrupt the body format. たとえば、CSS ファイルに HTML フッターを書き込んだ場合。For example, writing an HTML footer to a CSS file.

HasStarted は、ヘッダーが送信されたかどうかや本文が書き込まれたかどうかを示すために役立つヒントです。HasStarted is a useful hint to indicate if headers have been sent or the body has been written to.

Run デリゲートでは、next パラメーターは受け取られません。Run delegates don't receive a next parameter. 最初の Run デリゲートが常に終点となり、パイプラインが終了されます。The first Run delegate is always terminal and terminates the pipeline. Run は規則です。Run is a convention. 一部のミドルウェア コンポーネントでは、パイプラインの最後に実行される Run[Middleware] メソッドが公開されることがあります。Some middleware components may expose Run[Middleware] methods that run at the end of the pipeline:

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

コードのコメントを英語以外の言語に翻訳し表示したい場合、こちらの GitHub ディスカッション イシューにてお知らせください。If you would like to see code comments translated to languages other than English, let us know in this GitHub discussion issue.

前の例では、Run デリゲートによって応答に "Hello from 2nd delegate." が書き込まれ、その後、パイプラインが終了となります。In the preceding example, the Run delegate writes "Hello from 2nd delegate." to the response and then terminates the pipeline. 別の Use または Run デリゲートが Run デリゲートの後に追加される場合、そのデリゲートは呼び出されません。If another Use or Run delegate is added after the Run delegate, it's not called.

ミドルウェアの順序Middleware order

次の図は、ASP.NET Core MVC と Razor Pages アプリの完全な要求処理パイプラインを示しています。The following diagram shows the complete request processing pipeline for ASP.NET Core MVC and Razor Pages apps. 一般的なアプリでどのように既存のミドルウェアが順序付けされ、どこにカスタム ミドルウェアが追加されるかを確認できます。You can see how, in a typical app, existing middlewares are ordered and where custom middlewares are added. シナリオでの必要性に応じて、既存のミドルウェアの順序を変更したり、新しいカスタム ミドルウェアを挿入したりする方法については、完全に制御できます。You have full control over how to reorder existing middlewares or inject new custom middlewares as necessary for your scenarios.

ASP.NET Core のミドルウェア パイプライン

前の図のエンドポイント ミドルウェアでは、対応するアプリの種類 (MVC または Razor Pages) のフィルター パイプラインが実行されます。The Endpoint middleware in the preceding diagram executes the filter pipeline for the corresponding app type—MVC or Razor Pages.

ASP.NET Core のフィルター パイプライン

Startup.Configure メソッドでミドルウェア コンポーネントを追加する順序は、要求でミドルウェア コンポーネントが呼び出される順序および応答での逆の順序を定義します。The order that middleware components are added in the Startup.Configure method defines the order in which the middleware components are invoked on requests and the reverse order for the response. この順序は、セキュリティ、パフォーマンス、および機能にとって重要です。The order is critical for security, performance, and functionality.

次の Startup.Configure メソッドでは、セキュリティ関連のミドルウェア コンポーネントが推奨される順序で追加されています。The following Startup.Configure method adds security-related middleware components in the recommended order:

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

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

上のコードでは以下の操作が行われます。In the preceding code:

  • 個人のユーザー アカウントを使用して新しい Web アプリを作成するときに追加されないミドルウェアは、コメント アウトされています。Middleware that is not added when creating a new web app with individual users accounts is commented out.
  • すべてのミドルウェアを厳密にこの順序で追加する必要があるわけではありませんが、多くはそうする必要があります。Not every middleware needs to go in this exact order, but many do. 次に例を示します。For example:
    • UseCorsUseAuthenticationUseAuthorization は、示されている順序で追加する必要があります。UseCors, UseAuthentication, and UseAuthorization must go in the order shown.
    • 現時点では、こちらのバグのため、UseResponseCaching の前に UseCors を追加する必要があります。UseCors currently must go before UseResponseCaching due to this bug.

次の Startup.Configure メソッドにより、共通アプリ シナリオのためのミドルウェア コンポーネントが追加されます。The following Startup.Configure method adds middleware components for common app scenarios:

  1. 例外/エラー処理Exception/error handling
    • 開発環境でアプリを実行する場合:When the app runs in the Development environment:
      • 開発者例外ページ ミドルウェア (UseDeveloperExceptionPage) によりアプリの実行時エラーが報告されます。Developer Exception Page Middleware (UseDeveloperExceptionPage) reports app runtime errors.
      • データベース エラー ページ ミドルウェアによりデータベースの実行時エラーが報告されます。Database Error Page Middleware reports database runtime errors.
    • 運用環境でアプリを実行する場合:When the app runs in the Production environment:
      • 例外ハンドラー ミドルウェア (UseExceptionHandler) によって、後続のミドルウェアによってスローされた例外がキャッチされます。Exception Handler Middleware (UseExceptionHandler) catches exceptions thrown in the following middlewares.
      • HTTP Strict Transport Security プロトコル (HSTS) ミドルウェア (UseHsts) により Strict-Transport-Security ヘッダーが追加されます。HTTP Strict Transport Security Protocol (HSTS) Middleware (UseHsts) adds the Strict-Transport-Security header.
  2. HTTPS リダイレクト ミドルウェア (UseHttpsRedirection) により、HTTP 要求が HTTPS にリダイレクトされます。HTTPS Redirection Middleware (UseHttpsRedirection) redirects HTTP requests to HTTPS.
  3. 静的ファイル ミドルウェア (UseStaticFiles) によって静的ファイルが返され、さらなる要求の処理がスキップされます。Static File Middleware (UseStaticFiles) returns static files and short-circuits further request processing.
  4. Cookie ポリシー ミドルウェア (UseCookiePolicy) により、アプリを EU の一般データ保護規制 (GDPR) に準拠させます。Cookie Policy Middleware (UseCookiePolicy) conforms the app to the EU General Data Protection Regulation (GDPR) regulations.
  5. ルーティング ミドルウェア (UseRouting) により、要求がルーティングされます。Routing Middleware (UseRouting) to route requests.
  6. 認証ミドルウェア (UseAuthentication) により、ユーザーがセキュリティで保護されたリソースにアクセスする前に、ユーザーの認証が試行されます。Authentication Middleware (UseAuthentication) attempts to authenticate the user before they're allowed access to secure resources.
  7. 承認ミドルウェア (UseAuthorization) により、ユーザーがセキュリティで保護されたリソースにアクセスすることが承認されます。Authorization Middleware (UseAuthorization) authorizes a user to access secure resources.
  8. セッション ミドルウェア (UseSession) により、セッション状態が確立され保持されます。Session Middleware (UseSession) establishes and maintains session state. アプリでセッション状態が使用されている場合は、Cookie ポリシー ミドルウェアの後、MVC ミドルウェアの前に、セッション ミドルウェアを呼び出します。If the app uses session state, call Session Middleware after Cookie Policy Middleware and before MVC Middleware.
  9. エンドポイント ルーティング ミドルウェア (MapRazorPages を含む UseEndpoints) により、Razor Pages エンドポイントが要求パイプラインに追加されます。Endpoint Routing Middleware (UseEndpoints with MapRazorPages) to add Razor Pages endpoints to the request pipeline.
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();
    });
}

前のコード例では、各ミドルウェアの拡張メソッドが Microsoft.AspNetCore.Builder 名前空間を通じて IApplicationBuilder で公開されています。In the preceding example code, each middleware extension method is exposed on IApplicationBuilder through the Microsoft.AspNetCore.Builder namespace.

パイプラインに追加された最初のミドルウェア コンポーネントは UseExceptionHandler です。UseExceptionHandler is the first middleware component added to the pipeline. そのため、例外ハンドラー ミドルウェアでは、以降の呼び出しで発生するすべての例外がキャッチされます。Therefore, the Exception Handler Middleware catches any exceptions that occur in later calls.

静的ファイル ミドルウェアはパイプラインの早い段階で呼び出されるので、要求を処理し、残りのコンポーネントを通過せずにショートさせることができます。Static File Middleware is called early in the pipeline so that it can handle requests and short-circuit without going through the remaining components. 静的ファイル ミドルウェアでは、承認チェックは提供されませんThe Static File Middleware provides no authorization checks. wwwroot の下にあるものも含め、この静的ファイル ミドルウェアによって提供されるすべてのファイルは、一般に公開されます。Any files served by Static File Middleware, including those under wwwroot, are publicly available. 静的ファイルを保護する方法については、「ASP.NET Core の静的ファイル」を参照してください。For an approach to secure static files, see ASP.NET Core の静的ファイル.

要求が静的ファイル ミドルウェアによって処理されない場合、要求は認証を実行する認証ミドルウェア (UseAuthentication) に渡されます。If the request isn't handled by the Static File Middleware, it's passed on to the Authentication Middleware (UseAuthentication), which performs authentication. 認証は、認証されない要求をショートさせません。Authentication doesn't short-circuit unauthenticated requests. 認証ミドルウェアは要求を認証しますが、承認 (および却下) は、MVC が特定の Razor ページまたは MVC コントローラーとアクションを選んだ後でのみ行われます。Although Authentication Middleware authenticates requests, authorization (and rejection) occurs only after MVC selects a specific Razor Page or MVC controller and action.

次の例は、静的ファイルの要求が応答圧縮ミドルウェアの前に静的ファイル ミドルウェアによって処理される、ミドルウェアの順序を示します。The following example demonstrates a middleware order where requests for static files are handled by Static File Middleware before Response Compression Middleware. 静的ファイルは、このミドルウェアの順序では圧縮されません。Static files aren't compressed with this middleware order. Razor Pages の応答は圧縮できます。The Razor Pages responses can be compressed.

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

    app.UseResponseCompression();

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

シングルページ アプリケーション (SPA) の場合、通常はミドルウェア パイプラインの最後に SPA ミドルウェア UseSpaStaticFiles を配置します。For Single Page Applications (SPAs), the SPA middleware UseSpaStaticFiles usually comes last in the middleware pipeline. SPA ミドルウェアは、次のために最後になります。The SPA middleware comes last:

  • 対応する要求に最初にその他のミドルウェアが応答するため。To allow all other middlewares to respond to matching requests first.
  • クライアント側ルーティングを使用する SPA がサーバー アプリに認識されないすべてのルートを実行するため。To allow SPAs with client-side routing to run for all routes that are unrecognized by the server app.

SPA の詳細については、ReactAngular プロジェクト テンプレートのガイドを参照してください。For more details on SPAs, see the guides for the React and Angular project templates.

Forwarded Headers Middleware の順序Forwarded Headers Middleware order

Forwarded Headers Middleware は、他のミドルウェアの前に実行する必要があります。Forwarded Headers Middleware should run before other middleware. この順序により、転送されるヘッダー情報に依存するミドルウェアが処理にヘッダー値を使用できます。This ordering ensures that the middleware relying on forwarded headers information can consume the header values for processing. 診断およびエラー処理ミドルウェアの後に Forwarded Headers Middleware を実行する方法については、「Forwarded Headers Middleware の順序」を参照してください。To run Forwarded Headers Middleware after diagnostics and error handling middleware, see Forwarded Headers Middleware order.

ミドルウェア パイプラインを分岐するBranch the middleware pipeline

Map 拡張メソッドは、パイプラインを分岐する規則として使われます。Map extensions are used as a convention for branching the pipeline. Map は、指定された要求パスの一致に基づいて、要求パイプラインを分岐します。Map branches the request pipeline based on matches of the given request path. 要求パスが指定されたパスで開始する場合、分岐が実行されます。If the request path starts with the given path, the branch is executed.

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

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

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

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

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

次の表は、前のコードを使用した http://localhost:1234 からの要求および応答を示しています。The following table shows the requests and responses from http://localhost:1234 using the previous code.

要求Request 応答Response
localhost:1234localhost:1234 Hello from non-Map delegate.Hello from non-Map delegate.
localhost:1234/map1localhost:1234/map1 Map Test 1Map Test 1
localhost:1234/map2localhost:1234/map2 Map Test 2Map Test 2
localhost:1234/map3localhost:1234/map3 Hello from non-Map delegate.Hello from non-Map delegate.

Map を使用すると、一致したパス セグメントが HttpRequest.Path から削除され、要求ごとに HttpRequest.PathBase に追加されます。When Map is used, the matched path segments are removed from HttpRequest.Path and appended to HttpRequest.PathBase for each request.

Map は入れ子をサポートします。次にその例を示します。Map supports nesting, for example:

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

Map では、次のように一度に複数のセグメントを照合できます。Map can also match multiple segments at once:

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 は、指定された述語の結果に基づいて、要求パイプラインを分岐します。MapWhen branches the request pipeline based on the result of the given predicate. Func<HttpContext, bool> という型の任意の述語を使って、要求をパイプラインの新しい分岐にマップできます。Any predicate of type Func<HttpContext, bool> can be used to map requests to a new branch of the pipeline. 次の例では、クエリ文字列変数 branch の存在を検出するために術後が使用されます。In the following example, a predicate is used to detect the presence of a query string variable branch:

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

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

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

次の表は、前のコードを使用した http://localhost:1234 からの要求および応答を示しています。The following table shows the requests and responses from http://localhost:1234 using the previous code:

要求Request 応答Response
localhost:1234localhost:1234 Hello from non-Map delegate.Hello from non-Map delegate.
localhost:1234/?branch=masterlocalhost:1234/?branch=master Branch used = masterBranch used = master

また UseWhen では、指定された述語の結果に基づいて、要求パイプラインが分岐されます。UseWhen also branches the request pipeline based on the result of the given predicate. MapWhen とは異なり、この分岐は、ショートしたり、ターミナル ミドルウェアが含まれたりしなければ、メイン パイプラインに再参加します。Unlike with MapWhen, this branch is rejoined to the main pipeline if it doesn't short-circuit or contain a terminal middleware:

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

前の例では、"Hello from main pipeline." の応答がIn the preceding example, a response of "Hello from main pipeline." すべての要求に対して書き込まれます。is written for all requests. 要求にクエリ文字列変数 branch が含まれる場合、メイン パイプラインの再参加前にその値がログに記録されます。If the request includes a query string variable branch, its value is logged before the main pipeline is rejoined.

組み込みミドルウェアBuilt-in middleware

ASP.NET Core には、次のミドルウェア コンポーネントが付属しています。ASP.NET Core ships with the following middleware components. "順番" 列には、要求を処理するパイプライン内のミドルウェアの配置と、ミドルウェアが要求処理を終了する条件に関するメモが記載されています。The Order column provides notes on middleware placement in the request processing pipeline and under what conditions the middleware may terminate request processing. ミドルウェアが要求を処理するパイプラインをショートサーキットし、下流のさらなるミドルウェアによる要求の処理を回避する場合、これは "ターミナル ミドルウェア" と呼ばれます。When a middleware short-circuits the request processing pipeline and prevents further downstream middleware from processing a request, it's called a terminal middleware. ショートサーキットについて詳しくは、「IApplicationBuilder を使用したミドルウェア パイプラインの作成」セクションをご覧ください。For more information on short-circuiting, see the Create a middleware pipeline with IApplicationBuilder section.

ミドルウェアMiddleware 説明Description 順番Order
認証Authentication 認証のサポートを提供します。Provides authentication support. HttpContext.User が必要な場所の前。Before HttpContext.User is needed. OAuth コールバックの終端。Terminal for OAuth callbacks.
承認Authorization 承認のサポートを提供します。Provides authorization support. 認証ミドルウェアの直後。Immediately after the Authentication Middleware.
Cookie ポリシーCookie Policy 個人情報の保存に関してユーザーからの同意を追跡し、secureSameSite など、cookie フィールドの最小要件を適用します。Tracks consent from users for storing personal information and enforces minimum standards for cookie fields, such as secure and SameSite. cookie を発行するミドルウェアの前。Before middleware that issues cookies. 次に例を示します。 認証、セッション、MVC (TempData)Examples: Authentication, Session, MVC (TempData).
CORSCORS クロス オリジン リソース共有を構成します。Configures Cross-Origin Resource Sharing. CORS を使うコンポーネントの前。Before components that use CORS. 現時点では、こちらのバグのため、UseResponseCaching の前に UseCors を追加する必要があります。UseCors currently must go before UseResponseCaching due to this bug.
診断Diagnostics 開発者の例外ページ、例外処理、状態コード ページ、および新しいアプリの既定の Web ページを提供する複数の独立したミドルウェア。Several separate middlewares that provide a developer exception page, exception handling, status code pages, and the default web page for new apps. エラーを生成するコンポーネントの前。Before components that generate errors. 例外または新しいアプリ用の既定の Web ページの提供の終端。Terminal for exceptions or serving the default web page for new apps.
転送されるヘッダーForwarded Headers プロキシされたヘッダーを現在の要求に転送します。Forwards proxied headers onto the current request. 更新されたフィールドを使用するコンポーネントの前。Before components that consume the updated fields. 例: スキーム、ホスト、クライアント IP、メソッド。Examples: scheme, host, client IP, method.
正常性チェックHealth Check ASP.NET Core アプリとその依存関係の正常性を、データベースの可用性などで確認します。Checks the health of an ASP.NET Core app and its dependencies, such as checking database availability. 要求が正常性チェックのエンドポイントと一致した場合の終端。Terminal if a request matches a health check endpoint.
ヘッダーの伝達Header Propagation HTTP ヘッダーを受信要求から送信 HTTP クライアント要求に伝達します。Propagates HTTP headers from the incoming request to the outgoing HTTP Client requests.
HTTP メソッドのオーバーライドHTTP Method Override メソッドをオーバーライドする受信 POST 要求を許可します。Allows an incoming POST request to override the method. 更新されたメソッドを使うコンポーネントの前。Before components that consume the updated method.
HTTPS リダイレクトHTTPS Redirection すべての HTTP 要求を HTTPS にリダイレクトします。Redirect all HTTP requests to HTTPS. URL を使うコンポーネントの前。Before components that consume the URL.
HTTP Strict Transport Security (HSTS)HTTP Strict Transport Security (HSTS) 特殊な応答ヘッダーを追加するセキュリティ拡張機能のミドルウェア。Security enhancement middleware that adds a special response header. 応答が送信される前と要求を変更するコンポーネントの後。Before responses are sent and after components that modify requests. 次に例を示します。 転送されるヘッダー、URL リライト。Examples: Forwarded Headers, URL Rewriting.
MVCMVC MVC または Razor Pages で要求を処理します。Processes requests with MVC/Razor Pages. 要求がルートと一致した場合の終端。Terminal if a request matches a route.
OWINOWIN OWIN ベースのアプリ、サーバー、およびミドルウェアと相互運用します。Interop with OWIN-based apps, servers, and middleware. OWIN ミドルウェアが要求を完全に処理した場合の終端。Terminal if the OWIN Middleware fully processes the request.
応答キャッシュResponse Caching 応答のキャッシュのサポートを提供します。Provides support for caching responses. キャッシュが必要なコンポーネントの前。Before components that require caching. UseResponseCaching の前に UseCORS を追加する必要があります。UseCORS must come before UseResponseCaching.
応答圧縮Response Compression 応答の圧縮のサポートを提供します。Provides support for compressing responses. 圧縮が必要なコンポーネントの前。Before components that require compression.
要求のローカライズRequest Localization ローカライズのサポートを提供します。Provides localization support. ローカリゼーションが重要なコンポーネントの前。Before localization sensitive components.
エンドポイント ルーティングEndpoint Routing 要求のルートを定義および制約します。Defines and constrains request routes. 一致するルートの終端。Terminal for matching routes.
SPASPA シングルページ アプリケーション (SPA) の既定のページを返し、ミドルウェア チェーン内のこの時点以降のすべての要求を処理します。Handles all requests from this point in the middleware chain by returning the default page for the Single Page Application (SPA) チェーンの終わりで、静的ファイルや MVC アクションなどにサービスを提供する他のミドルウェアが優先されるようにするためです。Late in the chain, so that other middleware for serving static files, MVC actions, etc., takes precedence.
セッションSession ユーザー セッションの管理のサポートを提供します。Provides support for managing user sessions. セッションが必要なコンポーネントの前。Before components that require Session.
静的ファイルStatic Files 静的ファイルとディレクトリ参照に対応するサポートを提供します。Provides support for serving static files and directory browsing. 要求がファイルと一致した場合の終端。Terminal if a request matches a file.
URL 書き換えURL Rewrite URL の書き換えと要求のリダイレクトのサポートを提供します。Provides support for rewriting URLs and redirecting requests. URL を使うコンポーネントの前。Before components that consume the URL.
WebSocketWebSockets WebSocket プロトコルを有効にします。Enables the WebSockets protocol. WebSocket 要求を受け入れる必要があるコンポーネントの前。Before components that are required to accept WebSocket requests.

その他の技術情報Additional resources

作成者: Rick AndersonSteve SmithBy Rick Anderson and Steve Smith

ミドルウェアとは、要求と応答を処理するために、アプリのパイプラインに組み込まれたソフトウェアです。Middleware is software that's assembled into an app pipeline to handle requests and responses. 各コンポーネントで次の処理を実行します。Each component:

  • 要求をパイプライン内の次のコンポーネントに渡すかどうかを選択します。Chooses whether to pass the request to the next component in the pipeline.
  • パイプラインの次のコンポーネントの前または後に作業を実行できます。Can perform work before and after the next component in the pipeline.

要求デリゲートは、要求パイプラインの構築に使用されます。Request delegates are used to build the request pipeline. 要求デリゲートは、各 HTTP 要求を処理します。The request delegates handle each HTTP request.

要求デリゲートは、RunMapUse の各拡張メソッドを使って構成されます。Request delegates are configured using Run, Map, and Use extension methods. 個々の要求デリゲートは、匿名メソッドとしてインラインで指定するか (インライン ミドルウェアと呼ばれます)、または再利用可能なクラスで定義することができます。An individual request delegate can be specified in-line as an anonymous method (called in-line middleware), or it can be defined in a reusable class. これらの再利用可能なクラスとインラインの匿名メソッドは、"ミドルウェア" です。"ミドルウェア コンポーネント" とも呼ばれます。These reusable classes and in-line anonymous methods are middleware, also called middleware components. 要求パイプライン内の各ミドルウェア コンポーネントは、パイプラインの次のコンポーネントを呼び出すか、パイプラインをショートさせます。Each middleware component in the request pipeline is responsible for invoking the next component in the pipeline or short-circuiting the pipeline. ショートサーキットしたミドルウェアは "ターミナル ミドルウェア" と呼ばれます。これによってさらなるミドルウェアによる要求の処理が回避されるためです。When a middleware short-circuits, it's called a terminal middleware because it prevents further middleware from processing the request.

HTTP ハンドラーとモジュールを ASP.NET Core ミドルウェアに移行する では、ASP.NET Core と ASP.NET 4.x の要求パイプラインの違いについて説明し、その他のミドルウェア サンプルが提供されています。HTTP ハンドラーとモジュールを ASP.NET Core ミドルウェアに移行する explains the difference between request pipelines in ASP.NET Core and ASP.NET 4.x and provides additional middleware samples.

IApplicationBuilder を使用したミドルウェア パイプラインの作成Create a middleware pipeline with IApplicationBuilder

ASP.NET Core 要求パイプラインは、順番に呼び出される一連の要求デリゲートで構成されています。The ASP.NET Core request pipeline consists of a sequence of request delegates, called one after the other. 次の図は、その概念を示しています。The following diagram demonstrates the concept. 実行のスレッドは黒い矢印をたどります。The thread of execution follows the black arrows.

要求の到着、3 つのミドルウェアによる処理、アプリからの応答の送信を示す要求処理パターン。

各デリゲートは、次のデリゲートの前と後に操作を実行できます。Each delegate can perform operations before and after the next delegate. 例外処理デリゲートは、パイプラインの後のステージで発生する例外をキャッチできるように、パイプラインの早い段階で呼び出される必要があります。Exception-handling delegates should be called early in the pipeline, so they can catch exceptions that occur in later stages of the pipeline.

考えられる最も簡単な ASP.NET Core アプリは、1 つの要求デリゲートを設定してすべての要求を処理するものです。The simplest possible ASP.NET Core app sets up a single request delegate that handles all requests. この場合、実際の要求パイプラインは含まれません。This case doesn't include an actual request pipeline. 代わりに、すべての HTTP 要求に対応して単一の匿名関数が呼び出されます。Instead, a single anonymous function is called in response to every HTTP request.

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

最初の Run デリゲートが、パイプラインを終了します。The first Run delegate terminates the pipeline.

複数の要求デリゲートを Use と一緒にチェーンします。Chain multiple request delegates together with Use. next パラメーターは、パイプラインの次のデリゲートを表しますThe next parameter represents the next delegate in the pipeline. next パラメーターを "呼び出さない" ことで、パイプラインをショートさせることができます。You can short-circuit the pipeline by not calling the next parameter. 次の例で示すように、通常は、次のデリゲートの前と後の両方でアクションを実行できます。You can typically perform actions both before and after the next delegate, as the following example demonstrates:

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

デリゲートが次のデリゲートに要求を渡さない場合、これは "要求パイプラインのショートサーキット" と呼ばれます。When a delegate doesn't pass a request to the next delegate, it's called short-circuiting the request pipeline. 不要な処理を回避するために、ショートさせることが望ましい場合がよくあります。Short-circuiting is often desirable because it avoids unnecessary work. たとえば、静的ファイル ミドルウェアは、静的ファイルの要求を処理して残りのパイプラインをショートサーキットすることにより、"ターミナル ミドルウェア" として動作させることができます。For example, Static File Middleware can act as a terminal middleware by processing a request for a static file and short-circuiting the rest of the pipeline. 後続の処理を終了させるミドルウェアの前にパイプラインに追加されたミドルウェアでは、その next.Invoke ステートメントの後も引き続きコードが処理されます。Middleware added to the pipeline before the middleware that terminates further processing still processes code after their next.Invoke statements. ただし、既に送信された応答に対する書き込みの試行については、次の警告を参照してください。However, see the following warning about attempting to write to a response that has already been sent.

警告

応答がクライアントに送信された後に、next.Invoke を呼び出さないでください。Don't call next.Invoke after the response has been sent to the client. 応答が開始した後で HttpResponse を変更すると、例外がスローされます。Changes to HttpResponse after the response has started throw an exception. たとえば、ヘッダーや状態コードの設定などの変更があると、例外がスローされます。For example, changes such as setting headers and a status code throw an exception. next を呼び出した後で応答本文に書き込むと、次のようになります。Writing to the response body after calling next:

  • プロトコル違反が発生する可能性があります。May cause a protocol violation. たとえば、示されている Content-Length より多くを書き込んだ場合。For example, writing more than the stated Content-Length.
  • 本文の形式が破損する可能性があります。May corrupt the body format. たとえば、CSS ファイルに HTML フッターを書き込んだ場合。For example, writing an HTML footer to a CSS file.

HasStarted は、ヘッダーが送信されたかどうかや本文が書き込まれたかどうかを示すために役立つヒントです。HasStarted is a useful hint to indicate if headers have been sent or the body has been written to.

ミドルウェアの順序Middleware order

Startup.Configure メソッドでミドルウェア コンポーネントを追加する順序は、要求でミドルウェア コンポーネントが呼び出される順序および応答での逆の順序を定義します。The order that middleware components are added in the Startup.Configure method defines the order in which the middleware components are invoked on requests and the reverse order for the response. この順序は、セキュリティ、パフォーマンス、および機能にとって重要です。The order is critical for security, performance, and functionality.

次の Startup.Configure メソッドでは、セキュリティ関連のミドルウェア コンポーネントが推奨される順序で追加されています。The following Startup.Configure method adds security related middleware components in the recommended order:

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

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

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

    app.UseAuthentication();
    // app.UseSession();

    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });
}

上のコードでは以下の操作が行われます。In the preceding code:

  • 個人のユーザー アカウントを使用して新しい Web アプリを作成するときに追加されないミドルウェアは、コメント アウトされています。Middleware that is not added when creating a new web app with individual users accounts is commented out.
  • すべてのミドルウェアを厳密にこの順序で追加する必要があるわけではありませんが、多くはそうする必要があります。Not every middleware needs to go in this exact order, but many do. たとえば、UseCorsUseAuthentication は、示されている順序で追加する必要があります。For example, UseCors and UseAuthentication must go in the order shown.

次の Startup.Configure メソッドにより、共通アプリ シナリオのためのミドルウェア コンポーネントが追加されます。The following Startup.Configure method adds middleware components for common app scenarios:

  1. 例外/エラー処理Exception/error handling
    • 開発環境でアプリを実行する場合:When the app runs in the Development environment:
      • 開発者例外ページ ミドルウェア (UseDeveloperExceptionPage) によりアプリの実行時エラーが報告されます。Developer Exception Page Middleware (UseDeveloperExceptionPage) reports app runtime errors.
      • データベース エラー ページ ミドルウェア (Microsoft.AspNetCore.Builder.DatabaseErrorPageExtensions.UseDatabaseErrorPage) によりデータベースの実行時エラーが報告されます。Database Error Page Middleware (Microsoft.AspNetCore.Builder.DatabaseErrorPageExtensions.UseDatabaseErrorPage) reports database runtime errors.
    • 運用環境でアプリを実行する場合:When the app runs in the Production environment:
      • 例外ハンドラー ミドルウェア (UseExceptionHandler) によって、後続のミドルウェアによってスローされた例外がキャッチされます。Exception Handler Middleware (UseExceptionHandler) catches exceptions thrown in the following middlewares.
      • HTTP Strict Transport Security プロトコル (HSTS) ミドルウェア (UseHsts) により Strict-Transport-Security ヘッダーが追加されます。HTTP Strict Transport Security Protocol (HSTS) Middleware (UseHsts) adds the Strict-Transport-Security header.
  2. HTTPS リダイレクト ミドルウェア (UseHttpsRedirection) により、HTTP 要求が HTTPS にリダイレクトされます。HTTPS Redirection Middleware (UseHttpsRedirection) redirects HTTP requests to HTTPS.
  3. 静的ファイル ミドルウェア (UseStaticFiles) によって静的ファイルが返され、さらなる要求の処理がスキップされます。Static File Middleware (UseStaticFiles) returns static files and short-circuits further request processing.
  4. Cookie ポリシー ミドルウェア (UseCookiePolicy) により、アプリを EU の一般データ保護規制 (GDPR) に準拠させます。Cookie Policy Middleware (UseCookiePolicy) conforms the app to the EU General Data Protection Regulation (GDPR) regulations.
  5. 認証ミドルウェア (UseAuthentication) により、ユーザーがセキュリティで保護されたリソースにアクセスする前に、ユーザーの認証が試行されます。Authentication Middleware (UseAuthentication) attempts to authenticate the user before they're allowed access to secure resources.
  6. セッション ミドルウェア (UseSession) により、セッション状態が確立され保持されます。Session Middleware (UseSession) establishes and maintains session state. アプリでセッション状態が使用されている場合は、Cookie ポリシー ミドルウェアの後、MVC ミドルウェアの前に、セッション ミドルウェアを呼び出します。If the app uses session state, call Session Middleware after Cookie Policy Middleware and before MVC Middleware.
  7. MVC (UseMvc) を使い、要求パイプラインに MVC を追加します。MVC (UseMvc) to add MVC to the request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
        app.UseDatabaseErrorPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();
    app.UseCookiePolicy();
    app.UseAuthentication();
    app.UseSession();
    app.UseMvc();
}

前のコード例では、各ミドルウェアの拡張メソッドが Microsoft.AspNetCore.Builder 名前空間を通じて IApplicationBuilder で公開されています。In the preceding example code, each middleware extension method is exposed on IApplicationBuilder through the Microsoft.AspNetCore.Builder namespace.

パイプラインに追加された最初のミドルウェア コンポーネントは UseExceptionHandler です。UseExceptionHandler is the first middleware component added to the pipeline. そのため、例外ハンドラー ミドルウェアでは、以降の呼び出しで発生するすべての例外がキャッチされます。Therefore, the Exception Handler Middleware catches any exceptions that occur in later calls.

静的ファイル ミドルウェアはパイプラインの早い段階で呼び出されるので、要求を処理し、残りのコンポーネントを通過せずにショートさせることができます。Static File Middleware is called early in the pipeline so that it can handle requests and short-circuit without going through the remaining components. 静的ファイル ミドルウェアでは、承認チェックは提供されませんThe Static File Middleware provides no authorization checks. wwwroot の下にあるものも含め、この静的ファイル ミドルウェアによって提供されるすべてのファイルは、一般に公開されます。Any files served by Static File Middleware, including those under wwwroot, are publicly available. 静的ファイルを保護する方法については、「ASP.NET Core の静的ファイル」を参照してください。For an approach to secure static files, see ASP.NET Core の静的ファイル.

要求が静的ファイル ミドルウェアによって処理されない場合、要求は認証を実行する認証ミドルウェア (UseAuthentication) に渡されます。If the request isn't handled by the Static File Middleware, it's passed on to the Authentication Middleware (UseAuthentication), which performs authentication. 認証は、認証されない要求をショートさせません。Authentication doesn't short-circuit unauthenticated requests. 認証ミドルウェアは要求を認証しますが、承認 (および却下) は、MVC が特定の Razor ページまたは MVC コントローラーとアクションを選んだ後でのみ行われます。Although Authentication Middleware authenticates requests, authorization (and rejection) occurs only after MVC selects a specific Razor Page or MVC controller and action.

次の例は、静的ファイルの要求が応答圧縮ミドルウェアの前に静的ファイル ミドルウェアによって処理される、ミドルウェアの順序を示します。The following example demonstrates a middleware order where requests for static files are handled by Static File Middleware before Response Compression Middleware. 静的ファイルは、このミドルウェアの順序では圧縮されません。Static files aren't compressed with this middleware order. UseMvcWithDefaultRoute からの MVC 応答を圧縮することができます。The MVC responses from UseMvcWithDefaultRoute can be compressed.

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

    app.UseResponseCompression();

    app.UseMvcWithDefaultRoute();
}

Use、Run、および MapUse, Run, and Map

HTTP パイプラインを構成するには、UseRunMap を使います。Configure the HTTP pipeline using Use, Run, and Map. Use メソッドは、パイプラインをショートさせることができます (つまり next 要求デリゲートを呼び出さない場合)。The Use method can short-circuit the pipeline (that is, if it doesn't call a next request delegate). Run は規則であり、一部のミドルウェア コンポーネントは、パイプラインの最後に実行される Run[Middleware] メソッドを公開することがあります。Run is a convention, and some middleware components may expose Run[Middleware] methods that run at the end of the pipeline.

Map 拡張メソッドは、パイプラインを分岐する規則として使われます。Map extensions are used as a convention for branching the pipeline. Map は、指定された要求パスの一致に基づいて、要求パイプラインを分岐します。Map branches the request pipeline based on matches of the given request path. 要求パスが指定されたパスで開始する場合、分岐が実行されます。If the request path starts with the given path, the branch is executed.

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

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

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

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

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

次の表は、前のコードを使用した http://localhost:1234 からの要求および応答を示しています。The following table shows the requests and responses from http://localhost:1234 using the previous code.

要求Request 応答Response
localhost:1234localhost:1234 Hello from non-Map delegate.Hello from non-Map delegate.
localhost:1234/map1localhost:1234/map1 Map Test 1Map Test 1
localhost:1234/map2localhost:1234/map2 Map Test 2Map Test 2
localhost:1234/map3localhost:1234/map3 Hello from non-Map delegate.Hello from non-Map delegate.

Map を使用すると、一致したパス セグメントが HttpRequest.Path から削除され、要求ごとに HttpRequest.PathBase に追加されます。When Map is used, the matched path segments are removed from HttpRequest.Path and appended to HttpRequest.PathBase for each request.

MapWhen は、指定された述語の結果に基づいて、要求パイプラインを分岐します。MapWhen branches the request pipeline based on the result of the given predicate. Func<HttpContext, bool> という型の任意の述語を使って、要求をパイプラインの新しい分岐にマップできます。Any predicate of type Func<HttpContext, bool> can be used to map requests to a new branch of the pipeline. 次の例では、クエリ文字列変数 branch の存在を検出するために術後が使用されます。In the following example, a predicate is used to detect the presence of a query string variable branch:

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

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

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

次の表は、前のコードを使用した http://localhost:1234 からの要求および応答を示しています。The following table shows the requests and responses from http://localhost:1234 using the previous code.

要求Request 応答Response
localhost:1234localhost:1234 Hello from non-Map delegate.Hello from non-Map delegate.
localhost:1234/?branch=masterlocalhost:1234/?branch=master Branch used = masterBranch used = master

Map は入れ子をサポートします。次にその例を示します。Map supports nesting, for example:

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

Map では、次のように一度に複数のセグメントを照合できます。Map can also match multiple segments at once:

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

組み込みミドルウェアBuilt-in middleware

ASP.NET Core には、次のミドルウェア コンポーネントが付属しています。ASP.NET Core ships with the following middleware components. "順番" 列には、要求を処理するパイプライン内のミドルウェアの配置と、ミドルウェアが要求処理を終了する条件に関するメモが記載されています。The Order column provides notes on middleware placement in the request processing pipeline and under what conditions the middleware may terminate request processing. ミドルウェアが要求を処理するパイプラインをショートサーキットし、下流のさらなるミドルウェアによる要求の処理を回避する場合、これは "ターミナル ミドルウェア" と呼ばれます。When a middleware short-circuits the request processing pipeline and prevents further downstream middleware from processing a request, it's called a terminal middleware. ショートサーキットについて詳しくは、「IApplicationBuilder を使用したミドルウェア パイプラインの作成」セクションをご覧ください。For more information on short-circuiting, see the Create a middleware pipeline with IApplicationBuilder section.

ミドルウェアMiddleware 説明Description 順番Order
認証Authentication 認証のサポートを提供します。Provides authentication support. HttpContext.User が必要な場所の前。Before HttpContext.User is needed. OAuth コールバックの終端。Terminal for OAuth callbacks.
Cookie ポリシーCookie Policy 個人情報の保存に関してユーザーからの同意を追跡し、secureSameSite など、cookie フィールドの最小要件を適用します。Tracks consent from users for storing personal information and enforces minimum standards for cookie fields, such as secure and SameSite. cookie を発行するミドルウェアの前。Before middleware that issues cookies. 次に例を示します。 認証、セッション、MVC (TempData)Examples: Authentication, Session, MVC (TempData).
CORSCORS クロス オリジン リソース共有を構成します。Configures Cross-Origin Resource Sharing. CORS を使うコンポーネントの前。Before components that use CORS.
診断Diagnostics 開発者の例外ページ、例外処理、状態コード ページ、および新しいアプリの既定の Web ページを提供する複数の独立したミドルウェア。Several separate middlewares that provide a developer exception page, exception handling, status code pages, and the default web page for new apps. エラーを生成するコンポーネントの前。Before components that generate errors. 例外または新しいアプリ用の既定の Web ページの提供の終端。Terminal for exceptions or serving the default web page for new apps.
転送されるヘッダーForwarded Headers プロキシされたヘッダーを現在の要求に転送します。Forwards proxied headers onto the current request. 更新されたフィールドを使用するコンポーネントの前。Before components that consume the updated fields. 例: スキーム、ホスト、クライアント IP、メソッド。Examples: scheme, host, client IP, method.
正常性チェックHealth Check ASP.NET Core アプリとその依存関係の正常性を、データベースの可用性などで確認します。Checks the health of an ASP.NET Core app and its dependencies, such as checking database availability. 要求が正常性チェックのエンドポイントと一致した場合の終端。Terminal if a request matches a health check endpoint.
HTTP メソッドのオーバーライドHTTP Method Override メソッドをオーバーライドする受信 POST 要求を許可します。Allows an incoming POST request to override the method. 更新されたメソッドを使うコンポーネントの前。Before components that consume the updated method.
HTTPS リダイレクトHTTPS Redirection すべての HTTP 要求を HTTPS にリダイレクトします。Redirect all HTTP requests to HTTPS. URL を使うコンポーネントの前。Before components that consume the URL.
HTTP Strict Transport Security (HSTS)HTTP Strict Transport Security (HSTS) 特殊な応答ヘッダーを追加するセキュリティ拡張機能のミドルウェア。Security enhancement middleware that adds a special response header. 応答が送信される前と要求を変更するコンポーネントの後。Before responses are sent and after components that modify requests. 次に例を示します。 転送されるヘッダー、URL リライト。Examples: Forwarded Headers, URL Rewriting.
MVCMVC MVC または Razor Pages で要求を処理します。Processes requests with MVC/Razor Pages. 要求がルートと一致した場合の終端。Terminal if a request matches a route.
OWINOWIN OWIN ベースのアプリ、サーバー、およびミドルウェアと相互運用します。Interop with OWIN-based apps, servers, and middleware. OWIN ミドルウェアが要求を完全に処理した場合の終端。Terminal if the OWIN Middleware fully processes the request.
応答キャッシュResponse Caching 応答のキャッシュのサポートを提供します。Provides support for caching responses. キャッシュが必要なコンポーネントの前。Before components that require caching.
応答圧縮Response Compression 応答の圧縮のサポートを提供します。Provides support for compressing responses. 圧縮が必要なコンポーネントの前。Before components that require compression.
要求のローカライズRequest Localization ローカライズのサポートを提供します。Provides localization support. ローカリゼーションが重要なコンポーネントの前。Before localization sensitive components.
エンドポイント ルーティングEndpoint Routing 要求のルートを定義および制約します。Defines and constrains request routes. 一致するルートの終端。Terminal for matching routes.
セッションSession ユーザー セッションの管理のサポートを提供します。Provides support for managing user sessions. セッションが必要なコンポーネントの前。Before components that require Session.
静的ファイルStatic Files 静的ファイルとディレクトリ参照に対応するサポートを提供します。Provides support for serving static files and directory browsing. 要求がファイルと一致した場合の終端。Terminal if a request matches a file.
URL 書き換えURL Rewrite URL の書き換えと要求のリダイレクトのサポートを提供します。Provides support for rewriting URLs and redirecting requests. URL を使うコンポーネントの前。Before components that consume the URL.
WebSocketWebSockets WebSocket プロトコルを有効にします。Enables the WebSockets protocol. WebSocket 要求を受け入れる必要があるコンポーネントの前。Before components that are required to accept WebSocket requests.

その他の技術情報Additional resources