- Requests and domains
- Requests and servlets
- Request headers
- Responses
- The request timer
- SPDY
- Logging
- The environment
- Quotas and limits
Requests and domains
App Engine determines that an incoming request is intended for your application using the domain name of the request. A request whose domain name is
http://your_app_id.appspot.com
is routed to the application whose ID is
your_app_id
. Every application gets an
appspot.com
domain name for free.
appspot.com
domains also support subdomains of the form
subdomain-dot-your_app_id.appspot.com
, where
subdomain
can be any string allowed in one part of a domain
name (not
.
). Requests sent to any subdomain in this way are routed to your application.
You can set up a custom top-level domain using Google Apps. With Google Apps, you assign subdomains of your business's domain to various applications, such as Google Mail or Sites. You can also associate an App Engine application with a subdomain. For convenience, you can set up a Google Apps domain when you register your application ID, or later from the Administrator Console. See Deploying your Application on your Google Apps URL for more information.
Requests for these URLs all go to the version of your application that you have selected as the default version in the Administration Console. Each version of your application also has its own URL, so you can deploy and test a new version before making it the default version. The version-specific URL uses the version identifier from your app's configuration file in addition to the
appspot.com
domain name, in this pattern:
http://version_id-dot-latest-dot-your_app_id.appspot.com
You can also use subdomains with the version-specific URL:
http://subdomain-dot-version_id-dot-latest-dot-your_app_id.appspot.com
The domain name used for the request is included in the request data passed to the application. If you want your app to respond differently depending on the domain name used to access it (such as to restrict access to certain domains, or redirect to an official domain), you can check the request data (such as the
Host
request header) for the domain from within the application code and respond accordingly.
If your app uses backends , you can address requests to a specific backend and a specific instance with that backend. For more information about backend addressability, please see Properties of Backends .
Please note that in April of 2013, Google stopped issuing SSL certificates for double-wildcard domains hosted at
appspot.com
(i.e.
*.*.appspot.com
). If you rely on such URLs for HTTPS access to your application, please change any application logic to use "-dot-" instead of ".". For example, to access version "1" of application "myapp" use "https://1-dot-myapp.appspot.com" instead of "https://1.myapp.appspot.com." If you continue to use "https://1.myapp.appspot.com" the certificate will not match, which will result in an error for any User-Agent that expects the URL and certificate to match exactly.
Requests and servlets
When App Engine receives a web request for your application, it
invokes the servlet
that corresponds to the URL, as described in the application's
deployment descriptor
(the
web.xml
file in the
WEB-INF/
directory).
It uses the
Java Servlet API
, version 2.5, to provide the request data to the servlet and accept the response data
.
App Engine runs multiple instances of your application, 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. The number of instances can be adjusted automatically as traffic changes.
By default, each web server processes only one request at a time. If you mark your application as thread-safe, App Engine may dispatch multiple requests to each web server in parallel. To do so, simply add a
<threadsafe>true</threadsafe>
element to
appengine-web.xml
as described in
Using Concurrent Requests
.
The following example servlet class displays a simple message on the user's browser.
import java.io.IOException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class MyServlet extends HttpServlet {
@Override
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
resp.setContentType("text/plain");
resp.getWriter().println("Hello, world");
}
}
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.
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.
As a service to the app, App Engine adds some headers:
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.
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.
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
.
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.
Responses
App Engine calls the servlet with a request object and a response object, then waits for the servlet to populate the response object and return. When the servlet returns, the data on the response object is sent to the user.
App Engine does not support sending data to the client, performing more calculations in the application, then sending more data. In other words, App Engine does not support "streaming" data in response to a single request.
Dynamic responses are limited to 32MB. If a script handler generates a response larger than this limit, the server sends back an empty response with a 500 Internal Server Error status code. This limitation does not apply to responses that serve data from the Blobstore or Google Cloud Storage .
If the client sends HTTP headers with the request indicating that the client can accept compressed (gzipped) content, App Engine compresses the response data automatically and attaches the appropriate response headers. It uses both the
Accept-Encoding
and
User-Agent
request headers to determine if the client can reliably receive compressed responses. Custom clients can indicate that they are able to receive compressed responses by specifying both
Accept-Encoding
and
User-Agent
headers with a value of
gzip
. The
Content-Type
of the response is also used to determine whether compression is appropriate; in general, text-based content types are compressed, whereas binary content types are not.
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
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. In addition, 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 toprivate
, and add aVary: Accept-Encoding
header.If you have a Set-Cookie response header, the
Cache-Control
header will be set toprivate
(if it is not already more restrictive) and theExpires
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.