Request Headers and Responses

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 or amended by intermediate proxies before they reach the application.

Removed Headers

The following headers are removed from the request:

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

In addition, the header Strict-Transport-Security is removed from requests served to any domains other than appspot.com or *.appspot.com.

These headers relate to the transfer of the HTTP data between the client and server, and are transparent to the application. 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.

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.

Java supports the same set of incoming HTTP headers as listed above, including but not limited to the following:

• X-AppEngine-Https, with example header: "off"
• X-AppEngine-User-IP, with example header: "2602:306:3429:520:501f:4a71:9d2c:be5f"
• X-Cloud-Trace-Context, with example header: "18ff88cd7f38ff2bf9b79443..."

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

• X-AppEngine-User-Email, with example header: "ange@example.com"
• 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"

App Engine services may add additional request headers:

• 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 will also contain a HTTP 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.

In addition, the header Strict-Transport-Security is removed from responses served from any domains other than *.appspot.com.

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 Internet Service Providers) and browsers. If your script sets these headers, they will usually be unmodified, unless the response has a Set-Cookie header, or is generated for a user who is signed in using an administrator account. Static handlers will set these headers as directed by the configuration file. If you do not specify a Cache-Control, the server may set it to private, and add a Vary: Accept-Encoding header.

If you have 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.

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.

Date

Set to the current date and time.

Server

Set to Google Frontend.

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-Estimated-CPM-US-Dollars

An estimate of what 1,000 requests similar to this request would cost in US dollars.

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.