Routing Requests to Modules
HTTP requests from users can reach the appropriate module/version/instance in two ways: A request with a URL that ends at the domain level can be routed according to App Engine's default address routing rules. Alternatively, you can include a dispatch file that routes specific URL patterns according to your own rules.
Addressing instances
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 "instance", "version", "module", and "app-id" represent application and module attributes that you have defined yourself.
These two address forms are guaranteed to reach their target (if it exists). They cannot be intercepted and rerouted the dispatch file:
http://instance.version.module.app-id.appspot.com
- Sends a request to the named module, version, and instance. This address form can only be used by application administrators.
http://version.module.app-id.appspot.com
- Send the request to an available instance of the named module and version (round robin scheduling is used).
These address forms may be rerouted by the dispatch file:
http://module.app-id.appspot.com
- Send the request to an available instance of the default version of the named module (round robin scheduling is used).
http://version.app-id.appspot.com
- Send the request to an available instance of the given version of the default module.
http://app-id.appspot.com
- Send the request to an available instance of the default version of the default engine.
The default module is defined by explicitly giving a module the name "default," or by not including the name parameter in the module's config file. You can use the Admin Console to designate a default version for a module, when appropriate.
All modules are public by default, if you want to restrict access to a module, add the “login: admin” parameter to its handlers.
Dispatch file
In addition to routing based on canonical URLs (like those above), you can also route incoming requests to a specific module based on the path or hostname in the URL. For example, say that you want to route mobile requests like http://simple-sample.appspot.com/mobile/ to the mobile frontend, to route worker requests like http://simple-sample.appspot.com/work/ to the static backend and to serve all static content from the default module.
To do this you can create a custom routing with a dispatch.yaml file.
application: simple-sample
# No version required, this does routing independent of version
dispatch:
# Default module serves the typical web resources and all static resources.
- url: “*/favicon.ico”
module: default
# Default module serves simple hostname request.
- url: ""simple-sample.appspot.com/"
module: default
# Send all mobile traffic to the mobile frontend.
- url: "*/mobile/*"
module: mobile-frontend
# Send all work to the one static backend.
- url: "*/work/*"
module: static-backend
As you can see, dispatch.yaml includes support for glob characters (however, yaml syntax requires that you include such expressions in quotes to denote they are strings). Glob characters can be used only before the hostname and at the end of the path. If you prefer general routing rules that match many possible requests, you could specify the following:
# Send any path that begins with “simple-sample.appspot.com/mobile” to the mobile-frontend module.
- url: "simple-sample.appspot.com/mobile*"
module: mobile-frontend
# Send any domain/sub-domain with a path that starts with “work” to the static backend module.
- url: "*/work*"
module: static-backend
You can also write expressions that are more strict:
# Matches the path "/fun", but not "/fun2" or "/fun/other"
- url: "*/fun"
module: mobile-frontend
# Matches the hostname 'customer1.myapp.com', but not '1.customer1.myapp.com.
- url: "customer1.myapp.com/*"
module: static-backend