Request Headers and Responses

Region ID

The 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. For apps created after February 2020, REGION_ID.r is included in App Engine URLs. For existing apps created before this date, the region ID is optional in the URL.

Learn more about region IDs.

OK

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.

Request headers

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-Country or X-AppEngine-Country will be removed but X-Appengine-Cntry will not.

In addition, the following headers are removed from incoming requests because they relate to the transfer of the HTTP data between the client and server:

• Accept-Encoding
• Connection
• Keep-Alive
• Proxy-Authorization
• TE
• Trailer
• Transfer-Encoding

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.

Note: Entity headers (headers relating to the request body) are not sanitized or checked, so applications should not rely on them. In particular, the Content- MD5 request header is sent unmodified to the application, so may not match the MD5 hash of the content. Also, the Content-Encoding request header is not checked by the server, so if the client sends a gzipped request body, it will be sent in compressed form to the application.

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

Warning: CGI is included for backwards compatibility and its use is discouraged. Use WSGI if possible.

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:

X-Appengine-Country

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-Country header. Your application should handle the special country code ZZ (unknown country).

X-Appengine-Region

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.

X-Appengine-City

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.

X-Appengine-CityLatLong

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.

X-Cloud-Trace-Context

A unique identifier for the request used for Cloud Trace and Cloud Logging. There isn't an option to disable this header or choose the sampling rate for tracing since all App Engine standard environment apps are traced automatically.

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]

Shows http or https based on the protocol the client used to connect to your application.

The Google Cloud Load Balancer terminates all https connections, 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 https.

In addition, App Engine may set the following headers which are for internal use by App Engine:

• X-Appengine-Https
• X-Appengine-User-IP
• X-Appengine-Api-Ticket
• X-Appengine-Request-Log-Id
• X-Appengine-Default-Version-Hostname
• X-Appengine-Timeout-Ms

App Engine services may add additional request headers:

• For login:admin or login:required handlers specified in app.yaml, App Engine adds the following set of headers:

  • X-Appengine-User-Email, with example header: "[e-mail]"
  • 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"

• The Task Queue service adds additional headers to requests from that provide details about the task in the request, and the queue it is associated with.

• Requests from the Cron Service add the following header:

  X-Appengine-Cron: true

  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:

  X-Appengine-Inbound-Appid

  See the App Identity documentation for more details.

Request responses

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.

Headers removed

The following headers are ignored and removed from the response:

• Connection
• Content-Encoding*
• Content-Length
• Date
• Keep-Alive
• Proxy-Authenticate
• Server
• Trailer
• Transfer-Encoding
• Upgrade

* 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:

Cache-Control, Expires and Vary

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-Cookie header, or the response is generated for a user who is signed in using an administrator account.

If your app sets a Set-Cookie response header, the Cache-Control header will be set to private (if it is not already more restrictive) and the Expires header 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.

Note: The development server disables caching by default (for both script and static content), so that if you do not specify caching headers, you will not have cached content while developing your app.

If you use a webob-based framework (such as webapp or webapp2), the framework sets the Cache-Control header to no-cache by default, so you must override it if you want caching in your script handlers.

If your app does not set the Cache-Control response header, the server may set it to private and add a Vary: Accept-Encoding header.

For more information about caching, including the list of Vary values that the Google Frontend supports, see Response caching.

Content-Encoding

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: gzip header to indicate that the body is compressed. See the section on response compression for more detail.

Content-Length or Transfer-Encoding

The server always ignores the Content-Length header returned by the application. It will either set Content-Length to the length of the body (after compression, if compression is applied), or delete Content-Length, and use chunked transfer encoding (adding a Transfer-Encoding: chunked header).

Content-Type

If not specified by the application, the server will set a default Content-Type: text/html header.

Note: If you use a webob-based framework (such as webapp or webapp2), the Content-Type header is set to text/html; charset=utf-8 by default, so this default (without a charset property) does not apply.

Date

Set to the current date and time.

Server

Set to 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:

X-Appengine-Resource-Usage

The resources used by the request, including server-side time as a number of milliseconds.

Responses with resource usage statistics will be made uncacheable.

If the X-Appengine-BlobKey header is in the application's response, it and the optional 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-BlobKey and 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 Blob for details.

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 configuration documentation for more details.