REGION_ID is an abbreviated code that Google assigns
based on the region you select when you create your app. The code does not
correspond to a country or province, even though some region IDs may appear
similar to commonly used country and province codes. Including
REGION_ID.r in App Engine URLs is optional for
existing apps and will soon be required for all new apps.
To ensure a smooth transition, we are slowly updating App Engine to use region IDs. If we haven't updated your Google Cloud project yet, you won't see a region ID for your app. Since the ID is optional for existing apps, you don't need to update URLs or make other changes once the region ID is available for your existing apps.
Learn more about region IDs.
Use this reference page for details about what HTTP headers are supported as well as the request and response limits in App Engine. To understand how App Engine receives requests and sends responses, see How Requests Are Handled.
An incoming HTTP request includes the HTTP headers sent by the client. For security purposes, some headers are sanitized, amended, or removed by intermediate proxies before they reach the application.
Headers removed from incoming requests
The following headers are removed from incoming requests if a client sends them:
Headers with names that match the
X-Google-*pattern. This name pattern is reserved for Google.
Headers with names that match App Engine-specific headers. Only exact, case-insensitive matches are removed. For example, headers named
X-AppEngine-Countrywill be removed but
For example, the server may automatically send a gzipped response depending on
the value of the
Accept-Encoding request header. The application itself does
not need to know which content encodings the client can accept.
Requests and WSGI
The server determines which Python application object to call by comparing the URL of the request to the URL patterns in the app's configuration file. It then calls the application object using the arguments as defined in the WSGI standard. The application object performs actions appropriate to the request, then prepares a response and returns it as a list of strings.
Most applications use a framework, such as
webapp2, to handle WSGI requests.
webapp2 is included as part of the Python 2.7 runtime.
Requests and CGI
The server determines which Python handler script to run by comparing the URL of the request to the URL patterns in the app's configuration file. It then runs the script in a environment populated with the request data. As described in the CGI standard, the server puts the request data in environment variables and the standard input stream. The script performs actions appropriate to the request, then prepares a response and puts it on the standard output stream.
Most applications use a library to parse CGI requests and return CGI responses, such as the cgi module from the Python standard library, or a web framework that knows the CGI protocol (such as webapp). You can refer to the CGI documentation for details about the environment variables and the format of the input stream data.
App Engine-specific headers
As a service to the app, App Engine adds the following headers to all requests:
- Country from which the request originated, as an ISO 3166-1
alpha-2 country code.
App Engine determines this code from the client's IP address. Note that
the country information is not derived from the WHOIS database; it's possible
that an IP address with country information in the WHOIS database will not have
country information in the
X-Appengine-Countryheader. Your application should handle the special country code
- Name of region from which the request originated. This value only makes
sense in the context of the country in
X -Appengine-Country. For example, if the country is "US" and the region is "ca", that "ca" means "California", not Canada. The complete list of valid region values is found in the ISO-3166-2 standard.
- Name of the city from which the request originated. For example, a request
from the city of Mountain View might have the header value
mountain view. There is no canonical list of valid values for this header.
- Latitude and longitude of the city from which the request originated. This string might look like "37.386051,-122.083851" for a request from Mountain View.
- A unique identifier for the request used for Cloud Trace and Cloud Logging.
X-Forwarded-For: [CLIENT_IP(s)], [global forwarding rule IP]
A comma-delimited list of IP addresses through which the client request has been routed. The first IP in this list is generally the IP of the client that created the request. The subsequent IPs provide information about proxy servers that also handled the request before it reached the application server. For example:
X-Forwarded-For: clientIp, proxy1Ip, proxy2Ip
X-Forwarded-Proto [http | https]
httpsbased on the protocol the client used to connect to your application.
The Google Cloud Load Balancer terminates all
httpsconnections, and then forwards traffic to App Engine instances over
http. For example, if a user requests access to your site via
https://PROJECT_ID.REGION_ID.r.appspot.com, the X- Forwarded-Proto header value is
In addition, App Engine may set the following headers which are for internal use by App Engine:
login:requiredhandlers specified in
app.yaml, App Engine adds the following set of headers:
X-Appengine-User-Email, with example header: "firstname.lastname@example.org"
X-Appengine-Auth-Domain,with example header: "example.com"
X-Appengine-User-ID, with example header: "100979712376541954724"
X-Appengine-User-Nickname, with example header: "ange"
X-Appengine-User-Organization, with example header: "example.com"
X-Appengine-User-Is-Admin, with example header: "1"
Requests from the Cron Service add the following header:
See Securing URLs for cron for more details.
Requests coming from other App Engine applications will include a header identifying the app making the request, if the requesting app is using the URL Fetch Service:
See the App Identity documentation for more details.
This HTTP header documentation only applies to responses to inbound HTTP requests. The response may be modified before it is returned to the client. For HTTP headers related to outbound requests originated by your App Engine code, see the header documentation for URLFetch.
The following headers are ignored and removed from the response:
* May be re-added if the response is compressed by App Engine.
Headers with non-ASCII characters in either the name or value are also removed.
Headers added or replaced
The following headers are added or replaced in the response:
These headers specify caching policy to intermediate web proxies (such as the Google Frontend and Internet Service Providers) and browsers. If your app sets these response headers, they will usually be unmodified unless your app also sets a
Set-Cookieheader, or the response is generated for a user who is signed in using an administrator account.
If your app sets a
Set-Cookieresponse header, the
Cache-Controlheader will be set to
private(if it is not already more restrictive) and the
Expiresheader will be set to the current date (if it is not already in the past). Generally, this will allow browsers to cache the response, but not intermediate proxy servers. This is for security reasons, since if the response was cached publicly, another user could subsequently request the same resource, and retrieve the first user's cookie.
If you use a webob-based framework (such as webapp or webapp2), the framework sets the
no-cacheby default, so you must override it if you want caching in your script handlers.
If your app does not set the
Cache-Controlresponse header, the server may set it to
privateand add a
For more information about caching, including the list of
Varyvalues that the Google Frontend supports, see Response caching.
Depending upon the request headers and response
Content-Type, the server may automatically compress the response body, as described above. In this case, it adds a
Content-Encoding: gzipheader to indicate that the body is compressed. See the section on response compression for more detail.
The server always ignores the
Content-Lengthheader returned by the application. It will either set
Content-Lengthto the length of the body (after compression, if compression is applied), or delete
Content-Length, and use chunked transfer encoding (adding a
If not specified by the application, the server will set a default
Set to the current date and time.
Google Frontend. The development server sets this to
Development/x, where x is the version number.
If you access dynamic pages on your site while signed in using an administrator account, App Engine includes per-request statistics in the response headers:
- An estimate of what 1,000 requests similar to this request would cost in US dollars.
- The resources used by the request, including server-side time as a number of milliseconds.
Responses with resource usage statistics will be made uncacheable.
X-Appengine-BlobKey header is in the application's response, it and the
X-Appengine-BlobRange header will be used to replace the body with
all or part of a blobstore blob's content. If
Content-Type is not specified by
the application, it will be set to the blob's MIME type. If a range is
requested, the response status will be changed to
206 Partial Content, and a
Content-Range header will be added. The
X-Appengine-BlobRange headers will be removed from the response. You do not
normally need to set these headers yourself, as the
blobstore_handlers.BlobstoreDownloadHandler class sets them. See Serving a
Response headers set in the application configuration
Custom HTTP Response headers can be set per URL for dynamic and static paths in
your application's configuration file. See the
http_headers sections in the
for more details.