How Requests are Handled

This document describes how your App Engine application receives requests and
sends responses.
For more details, see the
Request Headers reference.

If your application uses services,
you can address requests to a specific service or a specific version of that
service. For more information about service addressability, see
How Requests are
Routed.

Handling requests

Your application is responsible for starting a webserver and handling requests.
You can use any web framework that is available for your development language.

App Engine runs multiple instances of your application, and each
instance has its own web server for handling requests. Any request can be routed
to any instance, so consecutive requests from the same user are not necessarily
sent to the same instance. An instance can handle multiple requests
concurrently. The number of instances can be adjusted automatically as traffic
changes. You can also change the number of concurrent requests an instance can handle
by setting the max_concurrent_requests
element in your app.yaml file.

Quotas and limits

App Engine automatically allocates resources to your application as
traffic increases. However, this is bound by the following restrictions:

App Engine reserves automatic scaling capacity for applications with
low latency, where the application responds to requests in less than one
second. Applications with very high latency, such as over one second per
request for many requests, and high throughput require Silver, Gold, or
Platinum support. Customers with this level of support can request
higher throughput limits by contacting their support representative.

Applications that are heavily CPU-bound may also incur some additional latency
in order to efficiently share resources with other applications on the same
servers. Requests for static files are exempt from these latency limits.

Each incoming request to the application counts toward the Requests limit.
Data sent in response to a request counts toward the
Outgoing Bandwidth (billable) limit.

The following limits apply specifically to the use of request handlers:

Request limits

A maximum of ~15KB in request headers is allowed.

The total size of the request is limited to ~32MB.

All HTTP/2 requests will be translated into HTTP/1.1 requests when forwarded
to the application server.

SSL connections are terminated 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.

Response limits

Responses are buffered by 64k blocks.

The response size is unlimited.

The response time limit is one hour.

Unsupported HTTP requests

The following features are not supported by App Engine flexible environment:

HTTP/2 traffic to the backend service

Websockets

HTTP requests that directly access instances

Request headers

An incoming HTTP request includes the HTTP headers sent by the client. For
security purposes, some headers are sanitized or amended by intermediate proxies
before they reach the application.

Request responses

There are limits that apply to the response you generate, and the response may
be modified before it is returned to the client.

Disabling buffering

By default, all responses from App Engine are buffered in 64k-blocks. In
some cases, it might make sense to disable buffering and directly stream bytes
to the client. This is generally preferred when using hanging GETs or Server
Sent Events (SSEs). To disable buffering, you can set the X-Accel-Buffering
response header to no.

X-Accel-Buffering: no

Forcing HTTPS connections

For security reasons, all applications should encourage clients to connect over
https. You can use the Strict-Transport-Security header to instruct the
browser to prefer https over http for a given page or an entire domain, for
example:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Caution: You should implement HTTP Strict Transport Security with 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.