Azure Functions のトリガーとバインドAzure Functions HTTP triggers and bindings

この記事では、Azure Functions で HTTP トリガーと出力バインドを操作する方法について説明します。This article explains how to work with HTTP triggers and output bindings in Azure Functions.

HTTP トリガーは webhook に応答するようにカスタマイズすることができます。An HTTP trigger can be customized to respond to webhooks.

これは、Azure Functions の開発者向けリファレンス情報です。This is reference information for Azure Functions developers. Azure Functions を初めて使用する場合は、先に次のリソースを参照してください。If you're new to Azure Functions, start with the following resources:

ヒント

HTTP または webhook のバインディングを使用する予定がある場合は、不適切な HttpClient のインスタンス化によって生じるおそれのあるポートの枯渇を防止してください。If you plan to use the HTTP or WebHook bindings, plan to avoid port exhaustion that can be caused by improper instantiation of HttpClient. 詳細については、「How to manage connections in Azure Functions」(Azure Functions で接続を管理する方法) を参照してください。For more information, see How to manage connections in Azure Functions.

この記事のコードは、既定では Functions バージョン 2.x 以降で使用される .NET Core を使用する構文になっています。The code in this article defaults to the syntax which uses .NET Core, used in Functions version 2.x and higher. 1.x 構文については、1.x 関数テンプレートを参照してください。For information on the 1.x syntax, see the 1.x functions templates.

パッケージ - Functions 1.xPackages - Functions 1.x

HTTP バインディングは Microsoft.Azure.WebJobs.Extensions.Http NuGet パッケージ バージョン 1.x で提供されます。The HTTP bindings are provided in the Microsoft.Azure.WebJobs.Extensions.Http NuGet package, version 1.x. パッケージのソース コードは、azure-webjobs-sdk-extensions GitHub リポジトリにあります。Source code for the package is in the azure-webjobs-sdk-extensions GitHub repository.

このバインドのサポートは、すべての開発環境で自動的に提供されます。Support for this binding is automatically provided in all development environments. 手動でパッケージをインストールしたり、拡張機能を登録したりする必要はありません。You don't have to manually install the package or register the extension.

パッケージ - Functions 2.x 以降Packages - Functions 2.x and higher

HTTP バインディングは Microsoft.Azure.WebJobs.Extensions.Http NuGet パッケージ バージョン 3.x で提供されます。The HTTP bindings are provided in the Microsoft.Azure.WebJobs.Extensions.Http NuGet package, version 3.x. パッケージのソース コードは、azure-webjobs-sdk-extensions GitHub リポジトリにあります。Source code for the package is in the azure-webjobs-sdk-extensions GitHub repository.

このバインドのサポートは、すべての開発環境で自動的に提供されます。Support for this binding is automatically provided in all development environments. 手動でパッケージをインストールしたり、拡張機能を登録したりする必要はありません。You don't have to manually install the package or register the extension.

トリガーTrigger

HTTP トリガーでは、HTTP 要求で関数を呼び出すことができます。The HTTP trigger lets you invoke a function with an HTTP request. HTTP トリガーを使用して、サーバーなしの API を構築し、webhook に応答することができます。You can use an HTTP trigger to build serverless APIs and respond to webhooks.

既定では、HTTP トリガーによって、Functions 1.x では "HTTP 200 OK" と空の本文が返され、Functions 2.x 以降では "HTTP 204 コンテンツがありません" と空の本文が返されます。By default, an HTTP trigger returns HTTP 200 OK with an empty body in Functions 1.x, or HTTP 204 No Content with an empty body in Functions 2.x and higher. 応答を変更するには、HTTP 出力バインドを構成します。To modify the response, configure an HTTP output binding.

トリガー - 例Trigger - example

次の例は、クエリ文字列または HTTP 要求の本文で nameパラメーターを探す C# 関数を示しています。The following example shows a C# function that looks for a name parameter either in the query string or the body of the HTTP request. 戻り値は出力バインドの使われますが、戻り値の属性は必要ないことに注意してください。Notice that the return value is used for the output binding, but a return value attribute isn't required.

[FunctionName("HttpTriggerCSharp")]
public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] 
    HttpRequest req, ILogger log)
{
    log.LogInformation("C# HTTP trigger function processed a request.");

    string name = req.Query["name"];

    string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
    dynamic data = JsonConvert.DeserializeObject(requestBody);
    name = name ?? data?.name;

    return name != null
        ? (ActionResult)new OkObjectResult($"Hello, {name}")
        : new BadRequestObjectResult("Please pass a name on the query string or in the request body");
}

トリガー - 属性Trigger - attributes

C# クラス ライブラリと Java では、HttpTrigger 属性を使用して関数を構成できます。In C# class libraries and Java, the HttpTrigger attribute is available to configure the function.

属性のコンストラクターのパラメーター、Webhook の種類、ルートのテンプレートに承認レベルと許容される HTTP メソッドを設定できます。You can set the authorization level and allowable HTTP methods in attribute constructor parameters, webhook type, and a route template. これらの設定の詳細については、「トリガー - 構成」を参照してください。For more information about these settings, see Trigger - configuration.

この例では、HttpTrigger 属性の使用方法を示します。This example demonstrates how to use the HttpTrigger attribute.

[FunctionName("HttpTriggerCSharp")]
public static Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Anonymous)] HttpRequest req)
{
    ...
}

完全な例については、トリガーの例を参照してください。For a complete example, see the trigger example.

トリガー - 構成Trigger - configuration

次の表は、function.json ファイルと HttpTrigger 属性で設定したバインド構成のプロパティを説明しています。The following table explains the binding configuration properties that you set in the function.json file and the HttpTrigger attribute.

function.json のプロパティfunction.json property 属性のプロパティAttribute property [説明]Description
typetype 該当なしn/a 必須 - httpTrigger に設定する必要があります。Required - must be set to httpTrigger.
directiondirection 該当なしn/a 必須 - in に設定する必要があります。Required - must be set to in.
namename 該当なしn/a 必須 - 要求または要求本文の関数コードで使用される変数名。Required - the variable name used in function code for the request or request body.
authLevelauthLevel AuthLevelAuthLevel 関数を呼び出すために、要求にどのキーが存在する必要があるかを決定します。Determines what keys, if any, need to be present on the request in order to invoke the function. 承認レベルは、次のいずれかの値になります。The authorization level can be one of the following values:
  • anonymous—API キーは必要ありません。anonymous—No API key is required.
  • function—関数固有の API キーが必要です。function—A function-specific API key is required. 何も指定されなかった場合は、これが既定値になります。This is the default value if none is provided.
  • admin—マスター キーが必要です。admin—The master key is required.
詳しくは、承認キーに関するセクションをご覧ください。For more information, see the section about authorization keys.
methodsmethods メソッドMethods 関数が応答する HTTP メソッドの配列。An array of the HTTP methods to which the function responds. 指定しない場合、関数はすべての HTTP メソッドに応答します。If not specified, the function responds to all HTTP methods. HTTP エンドポイントのカスタマイズ」をご覧ください。See customize the HTTP endpoint.
routeroute RouteRoute 関数がどの要求 URL に応答するかを制御するルート テンプレートを定義します。Defines the route template, controlling to which request URLs your function responds. 何も指定しなかった場合の既定値は <functionname> です。The default value if none is provided is <functionname>. 詳しくは、「HTTP エンドポイントのカスタマイズ」をご覧ください。For more information, see customize the HTTP endpoint.
webHookTypewebHookType WebHookTypeWebHookType バージョン 1.x ランタイムでのみサポートされます。Supported only for the version 1.x runtime.

指定したプロバイダーの webhook レシーバーとして機能する HTTP トリガーを構成します。Configures the HTTP trigger to act as a webhook receiver for the specified provider. このプロパティを設定する場合は、methods プロパティを設定しないでください。Don't set the methods property if you set this property. webhook の種類は、次のいずれかの値になります。The webhook type can be one of the following values:
  • genericJson—特定のプロバイダー用のロジックを持たない汎用 webhook エンドポイントです。genericJson—A general-purpose webhook endpoint without logic for a specific provider. この設定では、要求が、HTTP POST を使用していてコンテンツの種類が application/json であるものだけに制限されます。This setting restricts requests to only those using HTTP POST and with the application/json content type.
  • github—関数は GitHub webhook に応答します。github—The function responds to GitHub webhooks. GitHub webhook に対して authLevel プロパティを使用しないでください。Do not use the authLevel property with GitHub webhooks. 詳しくは、この記事で後述する「GitHub webhook」セクションをご覧ください。For more information, see the GitHub webhooks section later in this article.
  • slack—関数は Slack webhook に応答します。slack—The function responds to Slack webhooks. Slack webhook に対して authLevel プロパティを使用しないでください。Do not use the authLevel property with Slack webhooks. 詳しくは、この記事で後述する「Slack webhook」セクションをご覧ください。For more information, see the Slack webhooks section later in this article.

トリガー - 使用方法Trigger - usage

トリガーの入力型は、HttpRequest またはカスタム型のいずれかとして宣言されています。The trigger input type is declared as either HttpRequest or a custom type. HttpRequest を選択した場合は、要求オブジェクトへのフル アクセスが取得されます。If you choose HttpRequest, you get full access to the request object. カスタム型 の場合、ランタイムは JSON 要求本文を解析して、オブジェクトのプロパティを設定しようとします。For a custom type, the runtime tries to parse the JSON request body to set the object properties.

HTTP エンドポイントのカスタマイズCustomize the HTTP endpoint

既定では、HTTP トリガーの関数を作成する際に、次の形式のルートを使用して関数のアドレスを指定できます。By default when you create a function for an HTTP trigger, the function is addressable with a route of the form:

http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>

HTTP トリガーの入力バインドで省略可能な route プロパティを使用すると、このルートをカスタマイズできます。You can customize this route using the optional route property on the HTTP trigger's input binding. たとえば、次の function.json ファイルでは HTTP トリガーの route プロパティを定義します。As an example, the following function.json file defines a route property for an HTTP trigger:

{
    "bindings": [
    {
        "type": "httpTrigger",
        "name": "req",
        "direction": "in",
        "methods": [ "get" ],
        "route": "products/{category:alpha}/{id:int?}"
    },
    {
        "type": "http",
        "name": "res",
        "direction": "out"
    }
    ]
}

この構成を使用すると、元のルートではなく、次のルートを使用して関数のアドレスを指定できるようになります。Using this configuration, the function is now addressable with the following route instead of the original route.

http://<APP_NAME>.azurewebsites.net/api/products/electronics/357

これにより、関数のコードはアドレス内で categoryid という 2 つのパラメーターをサポートできます。This allows the function code to support two parameters in the address, category and id.

パラメーターでは任意の Web API ルート制約を使用できます。You can use any Web API Route Constraint with your parameters. 次の C# 関数コードは両方のパラメーターを使用します。The following C# function code makes use of both parameters.

using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;

public static IActionResult Run(HttpRequest req, string category, int? id, ILogger log)
{
    var message = String.Format($"Category: {category}, ID: {id}");
    return (ActionResult)new OkObjectResult(message);
}

既定では、すべての関数のルートには api というプレフィックスが付きます。By default, all function routes are prefixed with api. host.json ファイルで http.routePrefix プロパティを使用すると、このプレフィックスをカスタマイズまたは削除できます。You can also customize or remove the prefix using the http.routePrefix property in your host.json file. 次の例では、host.json ファイル内でプレフィックスに空の文字列を使用することで、api ルート プレフィックスを削除します。The following example removes the api route prefix by using an empty string for the prefix in the host.json file.

{
    "http": {
    "routePrefix": ""
    }
}

ルート パラメーターの使用Using route parameters

関数の route パターンを定義したルート パラメーターは、各バインドで使用できます。Route parameters that defined a function's route pattern are available to each binding. たとえば、ルートが "route": "products/{id}" として定義されている場合、テーブル ストレージ バインドでは、バインド構成の {id} パラメーターの値を使用できます。For example, if you have a route defined as "route": "products/{id}" then a table storage binding can use the value of the {id} parameter in the binding configuration.

次の構成は、{id} パラメーターをバインドの rowKey に渡す方法を示しています。The following configuration shows how the {id} parameter is passed to the binding's rowKey.

{
    "type": "table",
    "direction": "in",
    "name": "product",
    "partitionKey": "products",
    "tableName": "products",
    "rowKey": "{id}"
}

クライアント ID の操作Working with client identities

関数アプリが App Service の認証と承認を使用している場合は、コードから認証されたクライアントに関する情報を確認することができます。If your function app is using App Service Authentication / Authorization, you can view information about authenticated clients from your code. この情報は、プラットフォームによって挿入された要求ヘッダーとして使用できます。This information is available as request headers injected by the platform.

また、この情報はバインディング データから参照することもできます。You can also read this information from binding data. この機能は、Functions 2.x 以降の Functions ランタイムのみで使用可能です。This capability is only available to the Functions runtime in 2.x and higher. また、現在のところ .NET 言語でのみ使用可能です。It is also currently only available for .NET languages.

認証されたクライアントに関する情報は、ClaimsPrincipal として使用できます。Information regarding authenticated clients is available as a ClaimsPrincipal. ClaimsPrincipal は、次の例に示すように、要求コンテキストの一部として使用可能です。The ClaimsPrincipal is available as part of the request context as shown in the following example:

using System.Net;
using Microsoft.AspNetCore.Mvc;
using System.Security.Claims;

public static IActionResult Run(HttpRequest req, ILogger log)
{
    ClaimsPrincipal identities = req.HttpContext.User;
    // ...
    return new OkObjectResult();
}

また、ClaimsPrincipal を単に追加のパラメーターとして関数シグネチャに含めることもできます。Alternatively, the ClaimsPrincipal can simply be included as an additional parameter in the function signature:

using System.Net;
using Microsoft.AspNetCore.Mvc;
using System.Security.Claims;
using Newtonsoft.Json.Linq;

public static void Run(JObject input, ClaimsPrincipal principal, ILogger log)
{
    // ...
    return;
}

承認キーAuthorization keys

関数を使用すると、開発中に HTTP 関数のエンドポイントにアクセスするのをより困難にするようにキーを使用できます。Functions lets you use keys to make it harder to access your HTTP function endpoints during development. 標準の HTTP トリガーでは、そのような API キーが要求内に存在する必要があります。A standard HTTP trigger may require such an API key be present in the request.

重要

キーは開発中に HTTP エンドポイントを難読化するのに役立つかもしれませんが、運用環境で HTTP トリガーを確保する方法としては意図されていません。While keys may help obfuscate your HTTP endpoints during development, they are not intended as a way to secure an HTTP trigger in production. 詳細については、運用環境で HTTP エンドポイントを保護するを参照してください。To learn more, see Secure an HTTP endpoint in production.

注意

Functions 1.x ランタイムでは、Webhook プロバイダーは、プロバイダーがサポートするものに応じて、さまざまな方法で要求を認可するためにキーを使用することがあります。In the Functions 1.x runtime, webhook providers may use keys to authorize requests in a variety of ways, depending on what the provider supports. これについては、Webhook とキーを参照してください。This is covered in Webhooks and keys. バージョン 2.x 以降の Functions ランタイムには、Webhook プロバイダーの組み込みサポートは含まれていません。The Functions runtime in version 2.x and higher does not include built-in support for webhook providers.

キーには、次の 2 つの種類があります。There are two types of keys:

  • ホスト キー:これらのキーは、関数アプリ内のすべての関数で共有されます。Host keys: These keys are shared by all functions within the function app. API キーとして使用した場合は、関数アプリ内のすべての関数がアクセスできます。When used as an API key, these allow access to any function within the function app.
  • 関数キー:これらのキーは、それらが定義されている特定の関数にのみ適用されます。Function keys: These keys apply only to the specific functions under which they are defined. API キーとして使用した場合は、その関数だけがアクセスできます。When used as an API key, these only allow access to that function.

各キーには、参照用に名前が付けられており、関数レベルおよびホスト レベルで "default" という名前の既定のキーがあります。Each key is named for reference, and there is a default key (named "default") at the function and host level. 関数キーが、ホスト キーよりも優先されます。Function keys take precedence over host keys. 2 つのキーが同じ名前で定義されている場合は、関数キーが使用されます。When two keys are defined with the same name, the function key is always used.

各関数アプリには特別なマスター キーもあります。Each function app also has a special master key. このキーは_masterという名前のホスト キーで、ランタイム API への管理アクセスを提供します。This key is a host key named _master, which provides administrative access to the runtime APIs. このキーを取り消すことはできません。This key cannot be revoked. 認可レベルをadminに設定すると、要求でマスター キーを使用する必要があります。 その他のキーを使用すると認可エラーになります。When you set an authorization level of admin, requests must use the master key; any other key results in authorization failure.

注意事項

マスター キーによって付与された関数 app の権限が昇格しているため、このキーを第三者と共有したり、ネイティブ クライアント アプリケーションに配布したりしないでください。Due to the elevated permissions in your function app granted by the master key, you should not share this key with third parties or distribute it in native client applications. 管理者承認レベルを選択する場合は注意が必要です。Use caution when choosing the admin authorization level.

キーを入手するObtaining keys

キーは関数アプリの一部として Azure に格納され、保存中は暗号化されます。Keys are stored as part of your function app in Azure and are encrypted at rest. キーを表示には、新しい値を作成したり、新しい値にキーをロールしたり、Azure ポータルで HTTP トリガー機能に移動して、管理を選択します。To view your keys, create new ones, or roll keys to new values, navigate to one of your HTTP-triggered functions in the Azure portal and select Manage.

ポータルでのファンクション キーを管理します。

Key Management API を使用して、関数キーをプログラムで取得することができます。You may obtain function keys programmatically by using Key management APIs.

API キーの承認API key authorization

ほとんどの HTTP トリガー テンプレートには、要求内の API キーが必要です。Most HTTP trigger templates require an API key in the request. そのため、HTTP 要求は、通常は次の URL のようになります。So your HTTP request normally looks like the following URL:

https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?code=<API_KEY>

上記のように、キーはcodeというクエリ文字列変数に含めることができます。The key can be included in a query string variable named code, as above. x-functions-keyHTTP ヘッダーに含めることもできます。It can also be included in an x-functions-key HTTP header. キーの値には、関数のために定義されている任意の関数キーまたは任意のホスト キーを指定できます。The value of the key can be any function key defined for the function, or any host key.

匿名要求を許可できます。この要求ではキーが不要です。You can allow anonymous requests, which do not require keys. マスター キーを使用するように要求することもできます。You can also require that the master key be used. 既定の承認レベルを変更するには、バインド JSON の authLevel プロパティを使用します。You change the default authorization level by using the authLevel property in the binding JSON. 詳しくは、「トリガー - 構成」をご覧ください。For more information, see Trigger - configuration.

注意

機能をローカルで実行する場合、指定された承認レベルの設定に関係なく、許可は無効になります。When running functions locally, authorization is disabled regardless of the specified authorization level setting. Azure に発行した後、トリガーのauthLevel設定が適用されます。After publishing to Azure, the authLevel setting in your trigger is enforced. コンテナーをローカルで実行する場合もキーが必要です。Keys are still required when running locally in a container.

運用環境で HTTP エンドポイントを保護します。Secure an HTTP endpoint in production

運用環境で、関数エンドポイントを完全に保護するには、次の関数アプリ レベルのセキュリティ オプションのいずれかの実装を検討してください。To fully secure your function endpoints in production, you should consider implementing one of the following function app-level security options:

  • 機能アプリの App サービス認証/認可をオンにします。Turn on App Service Authentication / Authorization for your function app. App Service プラットフォームでは、Azure Active Directory (AAD) といくつかのサード パーティの ID プロバイダーを使用してクライアントを認証することができます。The App Service platform lets you use Azure Active Directory (AAD) and several third-party identity providers to authenticate clients. これを使用して、関数のカスタム認可ルールを実装し、関数コードのユーザー情報を操作できます。You can use this to implement custom authorization rules for your functions, and you can work with user information from your function code. 詳細については、「Azure App Service での認証および認可」および「クライアント ID の操作」を参照してください。To learn more, see Authentication and authorization in Azure App Service and Working with client identities.

  • 要求の認証に Azure API Management (APIM) を使用します。Use Azure API Management (APIM) to authenticate requests. APIM では、受信要求用のさまざまな API のセキュリティ オプションを提供します。APIM provides a variety of API security options for incoming requests. 詳細については、 API Management の認証ポリシーを参照してください。To learn more, see API Management authentication policies. APIM を適切に配置すると、APIM インスタンスの IP アドレスからの要求のみを受け入れるように関数アプリを設定できます。With APIM in place, you can configure your function app to accept requests only from the IP address of your APIM instance. 詳細については、IP アドレス制限を参照してください。To learn more, see IP address restrictions.

  • Azure App Service 環境 (ASE) で関数アプリをデプロイします。Deploy your function app to an Azure App Service Environment (ASE). ASE では、関数を実行するための専用のホスティング環境を提供します。ASE provides a dedicated hosting environment in which to run your functions. ASE では、すべての着信要求の認証に使用できる 1 つのフロント エンド ゲートウェイを構成できます。ASE lets you configure a single front-end gateway that you can use to authenticate all incoming requests. 詳細情報については、App Service 環境の Web アプリケーション ファイアウォール (WAF) を構成するを参照してください。For more information, see Configuring a Web Application Firewall (WAF) for App Service Environment.

これらの関数アプリレベル セキュリティ メソッドのいずれかを使用する場合は、HTTP トリガー関数の承認レベルを anonymous に設定する必要があります。When using one of these function app-level security methods, you should set the HTTP-triggered function authorization level to anonymous.

WebhooksWebhooks

注意

Webhook モードは、関数ランタイムのバージョン 1.x でのみ使用できます。Webhook mode is only available for version 1.x of the Functions runtime. この変更は、バージョン 2.x 以降での HTTP トリガーのパフォーマンスを向上させるために行われました。This change was made to improve the performance of HTTP triggers in version 2.x and higher.

バージョン 1.x では、Webhook テンプレートで Webhook ペイロードの追加検証が提供されます。In version 1.x, webhook templates provide additional validation for webhook payloads. バージョン 2.x 以降では、基本 HTTP トリガーは引き続き機能し、Webhook の推奨アプローチです。In version 2.x and higher, the base HTTP trigger still works and is the recommended approach for webhooks.

GitHub webhookGitHub webhooks

GitHub webhook に応答するには、まず、HTTP トリガーで関数を作成し、webHookType プロパティを github に設定します。To respond to GitHub webhooks, first create your function with an HTTP Trigger, and set the webHookType property to github. 次に、その URL と API キーを GitHub リポジトリの [webhook の追加] ページにコピーします。Then copy its URL and API key into the Add webhook page of your GitHub repository.

Slack webhookSlack webhooks

Slack webhook では、指定しなくてもトークンが自動的に生成されます。そのため、Slack によって生成されたトークンで、関数固有のキーを構成する必要があります。The Slack webhook generates a token for you instead of letting you specify it, so you must configure a function-specific key with the token from Slack. 承認キー」をご覧ください。See Authorization keys.

Webhook とキーWebhooks and keys

webhook の承認は、HTTP トリガーの一部である webhook レシーバー コンポーネントによって処理されますが、そのメカニズムは webhook の種類によって異なります。Webhook authorization is handled by the webhook receiver component, part of the HTTP trigger, and the mechanism varies based on the webhook type. ただし、各メカニズムはキーに依存します。Each mechanism does rely on a key. 既定では、"default" という名前の関数キーが使用されます。By default, the function key named "default" is used. 別のキーを使用するには、次のいずれかの方法で、要求と共にキー名を送信するように webhook プロバイダーを構成します。To use a different key, configure the webhook provider to send the key name with the request in one of the following ways:

  • クエリ文字列:プロバイダーにより、clientid クエリ文字列パラメーターでキー名 (https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?clientid=<KEY_NAME> など) が渡されます。Query string: The provider passes the key name in the clientid query string parameter, such as https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?clientid=<KEY_NAME>.
  • 要求ヘッダー:プロバイダーにより、x-functions-clientid ヘッダーでキー名が渡されます。Request header: The provider passes the key name in the x-functions-clientid header.

トリガー - 制限Trigger - limits

HTTP 要求の長さは 100 MB (104,857,600 バイト) に、URL の長さは 4 KB (4,096 バイト) バイトに制限されています。The HTTP request length is limited to 100 MB (104,857,600 bytes), and the URL length is limited to 4 KB (4,096 bytes). これらの制限は、ランタイムの Web.config ファイルhttpRuntime 要素で指定されています。These limits are specified by the httpRuntime element of the runtime's Web.config file.

HTTP トリガーを使用する関数が 230 秒以内に完了しない場合、Azure Load Balancer でタイムアウトが発生し、HTTP 502 エラーが返されます。If a function that uses the HTTP trigger doesn't complete within 230 seconds, the Azure Load Balancer will time out and return an HTTP 502 error. この関数は実行を継続しますが、HTTP 応答を返すことはできません。The function will continue running but will be unable to return an HTTP response. 実行時間が長い関数の場合は、非同期パターンに従い、要求の状態について ping で確認できる場所を返すことをお勧めします。For long-running functions, we recommend that you follow async patterns and return a location where you can ping the status of the request. 関数を実行できる時間については、スケールとホスティングに関するページの「従量課金プラン」を参照してください。For information about how long a function can run, see Scale and hosting - Consumption plan.

OutputOutput

HTTP 要求送信者に応答するには、HTTP 出力バインドを使用します。Use the HTTP output binding to respond to the HTTP request sender. このバインドには、HTTP トリガーが必要です。このバインドを使用すると、トリガーの要求に関連付けられている応答をカスタマイズすることができます。This binding requires an HTTP trigger and allows you to customize the response associated with the trigger's request. HTTP 出力バインドが提供されていない場合、HTTP トリガーによって、Functions 1.x では "HTTP 200 OK" と空の本文が返され、Functions 2.x 以降では "HTTP 204 コンテンツがありません" と空の本文が返されます。If an HTTP output binding is not provided, an HTTP trigger returns HTTP 200 OK with an empty body in Functions 1.x, or HTTP 204 No Content with an empty body in Functions 2.x and higher.

出力 - 構成Output - configuration

次の表は、function.json ファイルで設定したバインド構成のプロパティを説明しています。The following table explains the binding configuration properties that you set in the function.json file. C# クラス ライブラリには、function.json のこれらのプロパティに対応する属性プロパティはありません。For C# class libraries, there are no attribute properties that correspond to these function.json properties.

プロパティProperty [説明]Description
typetype http に設定する必要があります。Must be set to http.
directiondirection out に設定する必要があります。Must be set to out.
namename 応答の関数コードで使用される変数名、または戻り値を使うことを示す $returnThe variable name used in function code for the response, or $return to use the return value.

出力 - 使用方法Output - usage

HTTP 応答を送信するには、言語標準の応答パターンを使います。To send an HTTP response, use the language-standard response patterns. C# またはで C# スクリプトでは、関数の戻り値の型を IActionResult または Task<IActionResult> にします。In C# or C# script, make the function return type IActionResult or Task<IActionResult>. C# の場合、戻り値の属性は必要ありません。In C#, a return value attribute isn't required.

応答の例のため、トリガー例を参照してください。For example responses, see the trigger example.

host.json 設定host.json settings

このセクションでは、バージョン 2.x 以降でこのバインドに使用可能なグローバル構成設定について説明します。This section describes the global configuration settings available for this binding in versions 2.x and higher. 次の host.json ファイルの例には、このバインドのバージョン 2.x 以降の設定のみが含まれています。The example host.json file below contains only the version 2.x+ settings for this binding. バージョン 2.x 以降でのグローバル構成設定の詳細については、「Azure Functions の host.json のリファレンス」を参照してください。For more information about global configuration settings in versions 2.x and beyond, see host.json reference for Azure Functions.

注意

Functions 1.x の host.json のリファレンスについては、「host.json reference for Azure Functions 1.x (Azure Functions 1.x の host.json のリファレンス)」を参照してください。For a reference of host.json in Functions 1.x, see host.json reference for Azure Functions 1.x.

{
    "extensions": {
        "http": {
            "routePrefix": "api",
            "maxOutstandingRequests": 200,
            "maxConcurrentRequests": 100,
            "dynamicThrottlesEnabled": true,
            "hsts": {
                "isEnabled": true,
                "maxAge": "10"
            },
            "customHeaders": {
                "X-Content-Type-Options": "nosniff"
            }
        }
    }
}
プロパティProperty DefaultDefault [説明]Description
customHeaderscustomHeaders なしnone HTTP 応答でカスタム ヘッダーを設定できます。Allows you to set custom headers in the HTTP response. 前の例では、コンテンツ タイプのスニッフィングを避けるために、X-Content-Type-Options ヘッダーを応答に追加しています。The previous example adds the X-Content-Type-Options header to the response to avoid content type sniffing.
dynamicThrottlesEnableddynamicThrottlesEnabled true*true* この設定を有効にすると、要求処理パイプラインが、システム パフォーマンス カウンター (接続、スレッド、プロセス、メモリ、CPU など) を定期的にチェックし、カウンターのいずれかが組み込まれた上限閾値 (80%) を超えた場合は、カウンターが正常なレベルに戻るまで要求は 429 "Too Busy" 応答で拒否されます。When enabled, this setting causes the request processing pipeline to periodically check system performance counters like connections/threads/processes/memory/cpu/etc. and if any of those counters are over a built-in high threshold (80%), requests will be rejected with a 429 "Too Busy" response until the counter(s) return to normal levels.
*従量課金プランの既定値は、true です。*The default in a Consumption plan is true. 専用プランの既定値は、false です。The default in a Dedicated plan is false.
hstshsts 無効not enabled isEnabledtrue に設定されている場合、HstsOptions クラスで定義されているように、.NET Core の HTTP Strict Transport Security (HSTS) 動作が適用されます。When isEnabled is set to true, the HTTP Strict Transport Security (HSTS) behavior of .NET Core is enforced, as defined in the HstsOptions class. 上の例では、maxAge プロパティも 10 日間に設定されています。The above example also sets the maxAge property to 10 days. hsts のサポートされているプロパティは次のとおりです。Supported properties of hsts are:
プロパティProperty[説明]Description
excludedHostsexcludedHostsHSTS ヘッダーが追加されていないホスト名の文字列配列。A string array of host names for which the HSTS header isn't added.
includeSubDomainsincludeSubDomainsStrict-Transport-Security ヘッダーの includeSubDomain パラメーターが有効になっているかどうかを示すブール値。Boolean value that indicates whether the includeSubDomain parameter of the Strict-Transport-Security header is enabled.
maxAgemaxAgeStrict-Transport-Security ヘッダーの最長有効期間パラメーターを定義する文字列。String that defines the max-age parameter of the Strict-Transport-Security header.
preloadpreloadStrict-Transport-Security ヘッダーの事前読み込みパラメーターが有効になっているかどうかを示すブール値。Boolean that indicates whether the preload parameter of the Strict-Transport-Security header is enabled.
maxConcurrentRequestsmaxConcurrentRequests 100*100* 並列で実行される HTTP 関数の最大数。The maximum number of HTTP functions that are executed in parallel. これによりコンカレンシーを制御でき、リソース使用率の管理に役立ちます。This allows you to control concurrency, which can help manage resource utilization. たとえば、多くのシステム リソース (メモリ、CPU、ソケット) を消費する HTTP 関数があった場合、コンカレンシー率が高すぎると問題が発生します。For example, you might have an HTTP function that uses a lot of system resources (memory/cpu/sockets) such that it causes issues when concurrency is too high. または、サードパーティのサービスに対して要求を送信する関数があり、その呼び出し速度を制限する必要がある場合です。Or you might have a function that makes outbound requests to a third party service, and those calls need to be rate limited. このような場合は、調整を適用することができます。In these cases, applying a throttle here can help.
*従量課金プランでの既定値は 100 です。*The default for a Consumption plan is 100. 専用プランでの既定値は無制限です (-1)。The default for a Dedicated plan is unbounded (-1).
maxOutstandingRequestsmaxOutstandingRequests 200*200* 特定の時点で保持される未処理の要求の最大数。The maximum number of outstanding requests that are held at any given time. この制限には、キューに格納され、まだ実行が開始されていない要求と、処理中の実行が含まれます。This limit includes requests that are queued but have not started executing, as well as any in progress executions. この制限を超える受信要求は、429 "Too Busy" 応答で拒否されます。Any incoming requests over this limit are rejected with a 429 "Too Busy" response. これにより、呼び出し元は時間ベースの再試行戦略を採用でき、要求の最大待機時間の制御にも役立ちます。That allows callers to employ time-based retry strategies, and also helps you to control maximum request latencies. この設定は、スクリプト ホストの実行パス内で発生するキューのみを制御します。This only controls queuing that occurs within the script host execution path. ASP.NET 要求キューなどの他のキューは有効なままで、この設定の影響を受けません。Other queues such as the ASP.NET request queue will still be in effect and unaffected by this setting.
*従量課金プランでの既定値は 200 です。*The default for a Consumption plan is 200. 専用プランでの既定値は無制限です (-1)。The default for a Dedicated plan is unbounded (-1).
routePrefixroutePrefix apiapi すべてのルートに適用されるルート プレフィックス。The route prefix that applies to all routes. 既定のプレフィックスを削除するには、空の文字列を使用します。Use an empty string to remove the default prefix.

次のステップNext steps

Azure Functions のトリガーとバインドの詳細情報Learn more about Azure functions triggers and bindings