How Requests are Routed

Python |Java |Node.js |Go |Ruby |PHP |.NET

This page describes how HTTP requests from users reach the appropriate version of a service. Requests can be routed two ways:

• App Engine's default routing rules apply to requests with a URL that ends at the domain level.
• Alternatively, you can use a dispatch file that routes specific URL patterns according to your own rules.

These options apply only to deployed apps. When you are testing locally, the routing behavior depends on the particular runtime and development environment that you're using.

Requests and domains

App Engine determines that an incoming request is intended for your app by using the domain name of the request. A request whose domain name is http://MY_PROJECT_ID.appspot.com is routed to the app whose ID is MY_PROJECT_ID. Every app gets an appspot.com domain name for free.

The appspot.com domains also support subdomains of the form SUBDOMAIN-dot-MY_PROJECT_ID.appspot.com, where SUBDOMAIN can be any string allowed in one part of a domain name, excluding the . character. Requests that are sent to any subdomain in this way are routed to your app.

You can set up a custom top-level domain using G Suite and then assign subdomains of your business's domain to various apps, such as Google Mail or Sites. You can also associate an App Engine app with a subdomain. For more information about mapping a custom domain to your app, see Using Custom Domains and SSL.

Requests for these URLs all go to the version of your app that you configured to receive traffic. Each version of your app also has its own URL, so you can deploy and test a new version before configuring that version to receive traffic. The version-specific URL uses the ID of a specific version in addition to the appspot.com domain name, for example: http://VERSION_ID-dot-MY_PROJECT_ID.appspot.com. You can also use subdomains with the version-specific URL: http://SUBDOMAIN-dot-VERSION_ID-dot-MY_PROJECT_ID.appspot.com. See Routing via URL for more information and examples.

The domain name used for the request is included in the request data that is passed to your app. Therefore, you can use the request data to control how your app responds based on the domain name in the request. For example, if you want to redirect to an official domain, you can code you app to check the Host request header and then respond accordingly base on the domain name.

Note: Google recommends using the HTTPS protocol to send requests to your app. Google does not issue SSL certificates for double-wildcard domains that are hosted at appspot.com. Therefore, HTTPS requests must use the string "-dot-" as the URL notation, instead of "." for separating subdomains. You can use the simple "." URL notation with your own custom domains and other HTTP addresses. For more information, see the HTTP and HTTPS examples in the following sections.

Routing via URL

You can target an HTTP request with varying degrees of specificity. In the following examples, appspot.com can be replaced with your app's custom domain if you have one. The URL substrings VERSION_ID, SERVICE_ID, and MY_PROJECT_ID, each represent the resource IDs of your app.

Tip: You can use the following tools to retrieve the IDs of your app's resources:

Console

In the Cloud Platform Console, you can view the corresponding Instances, Services, and Versions pages.

gcloud

Run the gcloud app instances list command to list the resource IDs within a specific Cloud Platform project.

API

To programmatically retrieve resource IDs, see the list methods in the Admin API.

Default routing

The following URL patterns have a default routing behavior. Note that the default routing is overridden if there is a matching pattern that you have defined in your dispatch file:

• Sends the request to an available instance of the default service:

  https://MY_PROJECT_ID.appspot.com
  http://MY_CUSTOM_DOMAIN

  Request are received by any version that is configured for traffic in the default service.

• Sends a request to an available instance of a specific service:

  https://SERVICE_ID-dot-MY_PROJECT_ID.appspot.com
  http://SERVICE_ID.MY_CUSTOM_DOMAIN

  Requests are received by any version that is configured for traffic in the targeted service. If the service that you are targeting does not exist, the request gets soft routed.

• Sends a request to an available instance of a specific version in the default service:

  https://VERSION_ID-dot-MY_PROJECT_ID.appspot.com
  http://VERSION_ID.MY_CUSTOM_DOMAIN

  When a service is not targeted, requests are sent to the default service.

Soft routing

If a request matches the MY_PROJECT_ID.appspot.com portion of the hostname, but includes a service, version, or instance name that does not exist, then the request is routed to the default service. Soft routing does not apply to custom domains; requests to them will return a HTTP 404 status code if the hostname is invalid.

Targeted routing

The following URL patterns are guaranteed to reach their target, if they exist. These requests are never intercepted and rerouted by the patterns that you have defined in your dispatch file:

• Sends the request to an available instance of a specific service and version:

  https://VERSION_ID-dot-SERVICE_ID-dot-MY_PROJECT_ID.appspot.com
  http://VERSION_ID.SERVICE_ID.MY_PROJECT_ID.MY_CUSTOM_DOMAIN

Note: In the flexible environment, targeting an instance is not supported. It is not possible to send requests directly to a specific instance.

Default service

The default service is created when you deploy the initial version of your app to App Engine. Requests that specify no service or an invalid service are routed, to the default service. Those requests are then handled by the versions that you have configured to receive traffic within the default service. You can see which versions are configured for traffic in the Versions page of the Cloud Platform Console.

Example

To help demonstrate the URL patterns, assume an example Cloud Platform project with ID requestsProject exists and includes an app that is running two services and versions. The example app's default service includes version vFrontend, and the second service service2, includes version vBackend.

To target specific services and versions, you can use the following URL patterns:

1. To target the version in the default service using HTTPS, you can use:

   https://vFrontend-dot-default-dot-requestsProject.appspot.com
   https://vFrontend-dot-requestsProject.appspot.com
   

2. To target the vBackend version using a custom domain without HTTPS, you can use:

   http://vBackend.service2.example.net
   http://vBackend.example.net
   

   where requestsProject.appspot.com is mapped to the example.net domain.

Routing with a dispatch file

For URLs that use the patterns described earlier, you can create a dispatch file to override App Engine's routing rules and define your own custom routing rules. With a dispatch file, you can send incoming requests to a specific service based on the path or host name in the request URL.

Notes:

• The rules that you define in your dispatch file must use HTTP URL patterns that include the "." notation for separating subdomains. URLs defined with the HTTPS "-dot-" notation are not supported.
• Dispatch rules also apply to the URLs that you define in your cron file.

Creating a dispatch file

To define your own routing rules, you create and configure the dispatch.yaml file. The dispatch file should be placed either in the root of your project directory, or in the root directory of your default service.

You can define up to 20 routing rules in the dispatch file and each rule consists of both the service and url elements.

In the url element, you define the URL pattern within quotes, which can include the host name and URL path that are no longer than 100 characters. For the service element, you specify the name of the service that you want handling any incoming requests that match the URL pattern of the url element.

Tip: You can include glob patterns like the * wildcard character in the url element; however, those patterns can be used only before the host name and at the end of the URL path.

For example, you can create a dispatch file to route mobile requests like http://simple-sample.appspot.com/mobile/ to a mobile frontend, route worker requests like http://simple-sample.appspot.com/work/ to a static backend, and serve all static content from the default service:

dispatch:
  # Default service serves the typical web resources and all static resources.
  - url: "*/favicon.ico"
    service: default

  # Default service serves simple hostname request.
  - url: "simple-sample.appspot.com/"
    service: default

  # Send all mobile traffic to the mobile frontend.
  - url: "*/mobile/*"
    service: mobile-frontend

  # Send all work to the one static backend.
  - url: "*/work/*"
    service: static-backend

If you prefer general routing rules that match many possible requests, you can define rules with wider scopes. For example:

# Send any path that begins with “simple-sample.appspot.com/mobile” to the mobile-frontend service.
- url: "simple-sample.appspot.com/mobile*"
  service: mobile-frontend

# Send any domain/sub-domain with a path that starts with “work” to the static backend service.
- url: "*/work*"
  service: static-backend

You can also write expressions that are more strict:

# Matches the path "/fun", but not "/fun2" or "/fun/other".
- url: "*/fun"
  service: mobile-frontend

# Matches the hostname "customer1.myapp.com", but not "1.customer1.myapp.com".
- url: "customer1.myapp.com/*"
  service: static-backend