[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-20。"],[[["\u003cp\u003eThe \u003ccode\u003eREGION_ID\u003c/code\u003e is a Google-assigned code based on the region selected during app creation, included in App Engine URLs for apps created after February 2020, but it does not directly correspond to any specific country or province.\u003c/p\u003e\n"],["\u003cp\u003eApp Engine applications handle requests using multiple instances, each with its own web server, and consecutive requests from the same user are not guaranteed to go to the same instance.\u003c/p\u003e\n"],["\u003cp\u003eApp Engine automatically adjusts resources based on traffic, but reserves capacity for low-latency applications responding in under one second, with CPU-intensive applications potentially incurring additional latency.\u003c/p\u003e\n"],["\u003cp\u003eThere are specific limits for request headers (around 15KB) and total request size (around 32MB), while responses are buffered in 64KB blocks, and the maximum response time limit is one hour.\u003c/p\u003e\n"],["\u003cp\u003eFor security and better performance, App Engine applications should encourage HTTPS connections and can enforce it by using the \u003ccode\u003eStrict-Transport-Security\u003c/code\u003e header, while background work should be avoided and offloaded to services like Cloud Tasks for long-running jobs.\u003c/p\u003e\n"]]],[],null,["# How requests are handled\n\n### Region ID\n\nThe \u003cvar translate=\"no\"\u003eREGION_ID\u003c/var\u003e is an abbreviated code that Google assigns\nbased on the region you select when you create your app. The code does not\ncorrespond to a country or province, even though some region IDs may appear\nsimilar to commonly used country and province codes. For apps created after\nFebruary 2020, \u003cvar translate=\"no\"\u003eREGION_ID\u003c/var\u003e`.r` is included in\nApp Engine URLs. For existing apps created before this date, the\nregion ID is optional in the URL.\n\nLearn more\n[about region IDs](/appengine/docs/flexible/python/how-requests-are-routed#region-id). \nOK \nGo Java Node.js PHP Python Ruby .NET Custom\n\nThis document describes how your App Engine application receives requests and\nsends responses. For more details, see the\n[Request Headers reference](/appengine/docs/flexible/reference/request-headers).\n\nIf your application uses [services](/appengine/docs/an-overview-of-app-engine),\nyou can address requests to a specific service or a specific version of that\nservice. For more information about service addressability, see\n[How Requests are\nRouted](/appengine/docs/flexible/how-requests-are-routed).\n\nHandling requests\n-----------------\n\nYour application is responsible for starting a webserver and handling requests.\nYou can use any web framework that is available for your development language.\n\n\u003cbr /\u003e\n\nApp Engine runs multiple instances of your application, and each\ninstance has its own web server for handling requests. Any request can be routed\nto any instance, so consecutive requests from the same user are not necessarily\nsent to the same instance. An instance can handle multiple requests\nconcurrently. The number of instances can be adjusted automatically as traffic\nchanges.\n\n\nQuotas and limits\n-----------------\n\nApp Engine automatically allocates resources to your application as\ntraffic increases. However, this is bound by the following restrictions:\n\n- App Engine reserves automatic scaling capacity for applications with\n low latency, where the application responds to requests in less than one\n second.\n\n- Applications that are heavily CPU-bound may also incur some additional latency\n in order to efficiently share resources with other applications on the same\n servers. Requests for static files are exempt from these latency limits.\n\nEach incoming request to the application counts toward the **Requests** limit.\nData sent in response to a request counts toward the\n**Outgoing Bandwidth (billable)** limit.\n\nBoth HTTP and HTTPS (secure) requests count toward the **Requests** , **Incoming\nBandwidth (billable)** , and **Outgoing Bandwidth (billable)** limits. The\nGoogle Cloud console\n[Quota Details page](https://console.cloud.google.com/appengine/quotadetails)\nalso reports **Secure Requests** , **Secure Incoming Bandwidth** , and\n**Secure Outgoing Bandwidth** as separate values for informational purposes.\nOnly HTTPS requests count toward these values. For more information, see the\n[Quotas](/appengine/docs/quotas#Requests) page.\n\nThe following limits apply specifically to the use of request handlers:\n\n### Request limits\n\n- A maximum of \\~15KB in request headers is allowed.\n- The total size of the request is limited to \\~32MB.\n- All HTTP/2 requests will be translated into HTTP/1.1 requests when forwarded to the application server.\n- SSL connections end at the load balancer. Traffic from the load balancer is sent to the instance over an encrypted channel, and then forwarded to the application server over HTTP. The X-Forwarded-Proto header lets you understand if the origin request was HTTP or HTTPS.\n\n### Response limits\n\n- Responses are buffered by 64k blocks.\n- The response size is unlimited.\n- The response time limit is one hour.\n- The response header limit is 64 KB. Response headers that exceed this limit will return HTTP 502 errors, with logs showing `upstream sent too big header\n while reading response header from upstream`.\n\n### Unsupported HTTP requests\n\nThe following features are not supported by\nApp Engine flexible environment:\n\n- HTTP/2 traffic to the backend service.\n- HTTP requests that directly access instances.\n\nRequest headers\n---------------\n\nAn incoming HTTP request includes the HTTP headers sent by the client. For\nsecurity purposes, some headers are sanitized or amended by intermediate proxies\nbefore they reach the application.\n\nFor more information, see the\n[Request headers reference](/appengine/docs/flexible/reference/request-headers#request_headers).\n\n### Disabling buffering\n\nBy default, all responses from App Engine are buffered in 64k-blocks. In\nsome cases, it might make sense to disable buffering and directly stream bytes\nto the client. This is generally preferred when using hanging GETs or Server\nSent Events (SSEs). To disable buffering, you can set the `X-Accel-Buffering`\nresponse header to `no`.\n\nForcing HTTPS connections\n-------------------------\n\nFor security reasons, all applications should encourage clients to connect over\n`https`. To instruct the browser to prefer `https` over `http` for a given page\nor entire domain, set the `Strict-Transport-Security` header in your responses.\nFor example: \n\n Strict-Transport-Security: max-age=31536000; includeSubDomains\n\n\u003cbr /\u003e\n\n| **Caution:** Clients that have received the header in the past will refuse to connect if `https` becomes non-functional or is disabled for any reason. To learn more, see this [Cheat Sheet on HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html).\n\nHandling asynchronous background work\n-------------------------------------\n\nBackground work is any work that your app performs for a request after you have\ndelivered your HTTP response. Avoid performing background work in your app, and\nreview your code to make sure all asynchronous operations finish before you\ndeliver your response.\n\nFor long-running jobs, we recommend using [Cloud Tasks](/tasks). With\nCloud Tasks, HTTP requests are long-lived and return a response only\nafter any asynchronous work ends.\n| **Warning:** Performing asynchronous background work can result in higher billing. App Engine might scale up additional instances due to high CPU load, even if there are no active requests. Users may also experience increased latency because of requests waiting in the pending queue for available instances."]]
