app.yaml Reference

Python |Java |PHP |Go

You can configure your App Engine application's settings in the app.yaml file. This file specifies how URL paths correspond to request handlers and static files. The app.yaml file also contains information about the application code, such as the application ID and the latest version identifier.

Example

The following is an example of an app.yaml file for a Python application:

application: myapp
version: alpha-001
runtime: python27
api_version: 1
threadsafe: true

handlers:
- url: /
  script: home.app

- url: /index\.html
  script: home.app

- url: /stylesheets
  static_dir: stylesheets

- url: /(.*\.(gif|png|jpg))$
  static_files: static/\1
  upload: static/.*\.(gif|png|jpg)$

- url: /admin/.*
  script: admin.app
  login: admin

- url: /.*
  script: not_found.app

A script: directive can contain either a file path ending in .py, which means the script uses CGI, or a Python module path, with package names separated by dots, which means the script uses CGI.

Syntax

The syntax of app.yaml is the YAML format. For more information about this syntax, see the YAML website.

The YAML format supports comments. A line that begins with a pound (#) character is ignored:

# This is a comment.

URL and file path patterns use POSIX extended regular expression syntax, excluding collating elements and collation classes. Back-references to grouped matches (e.g. \1) are supported, as are these Perl extensions: \w \W \s \S \d \D.

Element Description
application

Optional. The application identifier. This is the identifier you selected when you created the application in the Google Cloud Platform Console.

application: myapp

If you do not specify the application in the file, use the --application option in the appcfg command when you deploy. This element is ignored when you deploy using the gcloud app deploy command.

api_version

Required. The version of the API in the given runtime environment used by this application. When Google releases a new version of a runtime environment's API, your application will continue to use the one for which it was written. To upgrade your application to the new API, you change this value and upload the upgraded code.

At this time, App Engine has one version of the python27 runtime environment: 1

auto_id_policy Optional. If you are setting entity identifiers automatically, you can change the method employed by setting the auto ID policy. The following are valid options:
default
Default. Uses scattered auto IDs that are large well-distributed integeres that are small enough to be reperesented by 64-bit floats.
legacy
The legacy option will be deprecated in a future release and will eventually be removed. For more information, see the blog post announcing this change.
builtins

Optional. The Python SDK includes a number of built-in handlers for common application functions. The builtins directive allows you to include specific handlers in app.yaml.

The following built-in handlers are available for your use:

appstats
Enables Appstats at /_ah/stats/, which you can use to measure your application's performance. In order to use Appstats, you also need to install the event recorder.
deferred
Enables the deferred handler at /_ah/queue/deferred. This builtin allows developers to use deferred.defer() to simplify the creation of Task Queue tasks. Also see Background work with the deferred library.
remote_api
Enables the remote_api builtin at /_ah/remote_api/. This builtin allows remote applications with the proper credentials to access the datastore remotely.
Example:
builtins:
- deferred: on
- appstats: on

The builtins directive is a special instance of the includes directive. Each builtin directive is equivalent, in Python, to an includes directive with an expanded path. For example:

builtins:
- name: on

Is equivalent to:

includes:
- $PYTHON_LIB/google/appengine/ext/builtins/name/

When you use builtins in your app.yaml file, any handlers that are defined by in the built-in include.yaml file will supersede any handlers that you define in your app.yaml file. However, if you include a file that then uses builtins or includes, the handlers are added by order of the include hierarchy. In other words, the handlers of the "parent" include are added before the builtins of the "child" includes, and so on.

For example, consider the following app.yaml, which uses the built-in appstats handlers:

handlers:
- url: /.*
  script: main.app
builtins:
- appstats: on

The resulting list of handlers is:

[/_ah/stats, /.*]

If the app.yaml uses an includes directive:

includes:
- included.yaml

And the included.yaml file uses builtins:

handlers:
- url: /.*
  script: main.app
builtins:
- appstats: on

The resultant list of handlers is now:

[/.*, /_ah/stats]

The order of placement of the builtins clause in a .yaml file doesn't change the behavior.

default_expiration

Optional. Sets a global default cache period for all static file handlers for an application. You can also configure a cache duration for specific static file handlers. The value is a string of numbers and units, separated by spaces, where units can be d for days, h for hours, m for minutes, and s for seconds. For example, "4d 5h" sets cache expiration to 4 days and 5 hours after the file is first requested. If omitted, the production server sets the expiration to 10 minutes.

Example: For example:
application: myapp
version: alpha-001
runtime: python27
api_version: 1
threadsafe: true

default_expiration: "4d 5h"

handlers:
# ...

For more information, see Static cache expiration.

error_handlers

Optional. Used to configure custom error pages that are returned for different error types.

This element can contain the following elements:

error_code
Optional. The error_code can be one of the following:
over_quota
Indicates the app has exceeded a resource quota
dos_api_denial
Indicates that the request was blocked by your app's DoS Protection configuration.
timeout
Served if a deadline is reached before there is a response from your app.

The error_code is optional; if it's not specified, the given file is the default error response for your app.

file
Each file entry indicates a static file that should be served in place of the generic error response. If you specify a file element without a corresponding error_code element, the static file will be the default error page for your app. The custom error data must be less than 10 kilobytes.
Example
error_handlers:
  - file: default_error.html

  - error_code: over_quota
    file: over_quota.html
handlers

Required. A list of URL patterns and descriptions of how they should be handled. App Engine can handle URLs by executing application code, or by serving static files uploaded with the code, such as images, CSS, or JavaScript.

See the Handlers and sub-elements syntax

includes

Optional. The includes directive allows you to include the configuration file for any library or service throughout your application. For example, you might include a user administration library as follows:

includes:
- lib/user_admin.yaml

App Engine resolves the included path in the following order:

  • Absolute or relative path to the working directory. The specified path resolves to a file.
  • Relative to the application's directory, which is also known as the basepath. The basepath and path resolve to a file.
  • Relative to the file that included the current file. The location of the referring file and the include path resolve to the included file.

If the include directive specifies a directory, then App Engine looks in that directory for a file called include.yaml. If the include directive is a file, then that specific file is included. Using includes retrieves only the following types of directives from the destination file (if present):

Included skip_files patterns are added to those in the including app.yaml, or to the default list if there is no explicit list in app.yaml.

inbound_services

Optional. Before an application can receive email or XMPP messages, the application must be configured to enable the service. You enable the service for a Python app by including an inbound_services section in the app.yaml file.

The following inbound services are available:

channel_presence
Registers your application for notifications when a client connects or disconnects from a channel.
mail
Allows your application to receive mail.
xmpp_message
Allows your application to receive instant messages.
xmpp_presence
Allows your application to receive a user's chat presence.
xmpp_subscribe
Allows your application to receive user subscription POSTs.
warmup
Enables warmup requests. See Configuring Warmup Requests.
Example:
inbound_services:
  - mail
  - warmup
instance_class

Optional. The instance class size for this service.

The following instance classes are available when specifying different scaling options:

automatic_scaling
When using automatic scaling, the F1, F2, F4, and F4_1G instance classes are available.
Default: F1 is assigned if you do not specify an instance class along with the automatic_scaling element.
basic_scaling
When using basic scaling, the B1, B2, B4, B4_1G, and B8 instance classes are available.
Default: B2 is assigned if you do not specify a instance class along with the basic_scaling element.
manual_scaling
When using manual scaling, the B1, B2, B4, B4_1G, and B8 instance classes are available.
Default: B2 is assigned if you do not specify a instance class along with the manual_scaling element.
libraries

Optional. The Python 2.7 runtime includes some third-party libraries. Some of these are available by default; others are only available if configured. You can specify which version you want to use by specifying the name and version values.

libraries:
- name: PIL
  version: "1.1.7"
- name: webob
  version: "latest"
        

Note than when you specify latest, the SDK determines the latest library version at deployment time. Once deployed, the library version will not change. The only way to get a different version of the library is to deploy again.

If you're developing an application that doesn't have users yet: you don't need to track new versions. But if your application is being actively used, beware: you might be surprised that your application starts using a new not-backward-compatible library version.

For a list of the included third-party libraries, see Third-party Libraries. You can install pure-python libraries using pip by setting up vendoring.

If you are using the flexible environment, see Using Python libraries in the flexible environment.

module

Note: Modules are now named Services and services are still declared in app.yaml files as modules, for example: module: service_name.

Required if creating a service. Optional for the default service. Each service and each version must have a name. A name can contain numbers, letters, and hyphens. It cannot be longer than 63 characters and cannot start or end with a hyphen. Choose a unique name for each service and each version. Don't reuse names between services and versions.

Also see service.

service

Services were formerly known as modules.

Currently, defining a service as: service: service_name is supported only by gcloud app deploy commands.

skip_files

Optional. The skip_files element specifies which files in the application directory are not to be uploaded to App Engine. The value is either a regular expression, or a list of regular expressions. Any filename that matches any of the regular expressions is omitted from the list of files to upload when the application is uploaded.

The skip_files has the following default:

skip_files:
- ^(.*/)?#.*#$
- ^(.*/)?.*~$
- ^(.*/)?.*\.py[co]$
- ^(.*/)?.*/RCS/.*$
- ^(.*/)?\..*$

The default pattern excludes Emacs backup files with names of the form #...# and ...~, .pyc and .pyo files, files in an RCS revision control directory, and Unix hidden files with names beginning with a dot (.).

To extend the above regular express list, copy and paste the above list into your app.yaml and add your own regular expressions. For example, to skip files whose names end in .bak in addition to the default patterns, add an entry like this to skip_files:

skip_files:
- ^(.*/)?#.*#$
- ^(.*/)?.*~$
- ^(.*/)?.*\.py[co]$
- ^(.*/)?.*/RCS/.*$
- ^(.*/)?\..*$
- ^(.*/)?\.bak$
threadsafe

Required. Configures your application to use concurrent requests. If using Python's threading library, the thread-local data, as returned by threading.local(), is cleared after each request.

threadsafe: [true | false]

Note: The threadsafe directive is required for Python 2.7 applications. threadsafe: true requires that all script handlers be WSGI ones. That is, each script must be specified in a script: directive a using Python module path, with package names separated by dots. The last component of a script: directive using a Python module path is the name of a global variable in the service: that variable must be a WSGI app, and is usually called app by convention.

version

Optional. A version specifier for the application code. App Engine retains a copy of your application for each version used. An administrator can change which major version of the application is default using the Google Cloud Platform Console, and can test non-default versions before making them default. The version specifier can contain lowercase letters, digits, and hyphens. It cannot begin with the prefix ah- and the names default and latest are reserved and cannot be used.

Note: Version names should begin with a letter, to distinguish them from numeric instances which are always specified by a number. This avoids the ambiguity with URLs like 123.my-service.appspot.com, which can be interpreted two ways: If version “123” exists, the target will be version “123” of the given service. If that version does not exist, the target will be instance number 123 of the default version of the service.

Each version of an application retains its own copy of app.yaml. When an application is uploaded, the version mentioned in the app.yaml file being uploaded is the version that gets created or replaced by the upload.

version: alpha-001

If you do not specify the version in the file, use the --version option in the appcfg command when you deploy. This element is ignored when you deploy using the gcloud app command.

Handlers element

The handlers element is a required element in the app.yaml. The element provides a list of URL patterns and descriptions of how they should be handled. App Engine can handle URLs by executing application code, or by serving static files uploaded with the code, such as images, CSS, or JavaScript.

Patterns are evaluated in the order they appear in the app.yaml file, from top to bottom. The first mapping whose pattern matches the URL is the one used to handle the request.

The following table lists the subelements of the handlers element and control the behavior for scripts, static files, static directories, and other settings.

Element Description>
application_readable Optional. Boolean. By default, files declared in static file handlers are uploaded as static data and are only served to end users. They cannot be read by an application. If this field is set to true, the files are also uploaded as code data so your application can read them. Both uploads are charged against your code and static data storage resource quotas.
auth_fail_action

Optional.` Describes the action taken when the login element is specified for a handler and the user is not logged in. Has two possible values:

redirect
Default. The user is redirected to the Google sign-in page, or /_ah/login_required if OpenID authentication is used. The user is redirected back to the application URL after signing in or creating an account.
unauthorized
The request is rejected with an HTTP 401 status code and an error message.

If an application needs different behavior, the application itself can implement the handling of user logins. See the Users API for more information.

The following example requires a login for the /profile/ directory and an administrator login for the /admin/ directory:

handlers:
- url: /profile/.*
  script: user_profile.app
  login: required

- url: /admin/.*
  script: admin.app
  login: admin

- url: /.*
  script: welcome.app

You can configure a handler to refuse access to protected URLs when the user is not signed in, instead of redirecting the user to the sign-in page, by adding auth_fail_action: unauthorized to the handler's configuration:

handlers:
- url: /secure_api/.*
  script: api_handler.app
  login: required
  auth_fail_action: unauthorized
env_variables

Optional. You can define environment variables in your app.yaml file to make them available to your application.

These variables will be available in the os.environ dictionary:
env_variables:
  DJANGO_SETTINGS_MODULE: 'myapp.settings'
expiration Optional. The length of time a static file served by this handler should to be cached by web proxies and browsers. The value is a string of numbers and units, separated by spaces, where units can be d for days, h for hours, m for minutes, and s for seconds. For example, "4d 5h" sets cache expiration to 4 days and 5 hours after the file is first requested. If omitted, the application's default_expiration is used. See Static cache expiration for more details.
http_headers

Optional. HTTP headers to use for all responses from these URLs.

Example
handlers:
- url: /images
  static_dir: static/images
  http_headers:
  X-Foo-Header: foo
  X-Bar-Header: bar value

CORS Support

One important use of this feature is to support cross-origin resource sharing (CORS), such as accessing files hosted by another App Engine app.

For example, you could have a game app mygame.appspot.com that accesses assets hosted by myassets.appspot.com. However, if mygame attempts to make a JavaScript XMLHttpRequest to myassets, it will not succeed unless the handler for myassets returns an Access-Control-Allow-Origin: response header containing the value http://mygame.appspot.com.

Here is how you would make your static file handler return that required response header value:

handlers:
- url: /images
  static_dir: static/images
  http_headers:
    Access-Control-Allow-Origin: http://mygame.appspot.com

Note: if you wanted to allow everyone to access your assets, you could use the wildcard '*', instead of http://mygame.appspot.com.

login

Optional. Determines whether the URL handler requires that the user is signed in. This element has three possible values:

optional
Default. Does not require that the user is signed in.
required
If the user has signed in, the handler proceeds normally. Otherwise, the action given in auth_fail_action is taken.
admin
As with required, performs auth_fail_action if the user is not signed in. In addition, if the user is not an administrator for the application, they are given an error message regardless of the auth_fail_action setting. If the user is an administrator, the handler proceeds.

When a URL handler with a login setting other than optional matches a URL, the handler first checks whether the user has signed in to the application using its authentication option. If not, by default, the user is redirected to the sign-in page. You can also use auth_fail_action to configure the app to simply reject requests for a handler from users who are not properly authenticated, instead of redirecting the user to the sign-in page.

Note: the admin login restriction is also satisfied for internal requests for which App Engine sets appropriate X-Appengine special headers. For example, cron scheduled tasks satisfy the admin restriction, because App Engine sets an HTTP header X-AppEngine-Cron: true on the respective requests. However, the requests would not satisfy the required login restriction, because cron scheduled tasks are not run as any user.

mime_type

Optional. If specified, all files served by this handler will be served using the specified MIME type. If not specified, the MIME type for a file will be derived from the file's filename extension.

For more information about the possible MIME media types, see the IANA MIME Media Types website

redirect_http_response_code

Optional. redirect_http_response_code is used with the secure setting to set the HTTP response code returned when performing a redirect required by how the secure setting is configured. redirect_http_response_code element has the following possible values:

301
Moved Permanently response code.
302
Found response code.
303
See Other response code.
307
Temporary Redirect response code.
Example
handlers:
- url: /youraccount/.*
  script: accounts.app
  login: required
  secure: always
  redirect_http_response_code: 301

When a user's query is redirected the HTTP status code will be set to the value of the redirect_http_response_code parameter. If the parameter is not present, 302 will be returned.

script

Optional. Specifies the path to the script from the application root directory:

handlers:
# The root URL (/) is handled by the WSGI application named "app" in home.py.
# No other URLs match this pattern.
- url: /
  script: home.app

# The URL /index.html is also handled by the home.py script.
- url: /index\.html
  script: home.app

# A regular expression can map parts of the URL to the path of the script.
- url: /browse/(books|videos|tools)
  script: \1.catalog.app

# All other URLs use the WSGI application named in "app" in not_found.py.
- url: /.*
  script: not_found.app

A script: directive must be a python import path, for example, package.module.app that points to a WSGI application. The last component of a script: directive using a Python module path is the name of a global variable in the module: that variable must be a WSGI app, and is usually called app by convention.

Note: just like for a Python import statement, each subdirectory that is a package must contain a file named __init__.py.

secure Optional. Any URL handler can use the secure setting, including script handlers and static file handlers. The secure element has the following possible values:
optional
Both HTTP and HTTPS requests with URLs that match the handler succeed without redirects. The application can examine the request to determine which protocol was used, and respond accordingly. This is the default when secure is not provided for a handler.
never
Requests for a URL that match this handler that use HTTPS are automatically redirected to the HTTP equivalent URL.
always
Requests for a URL that match this handler that do not use HTTPS are automatically redirected to the HTTPS URL with the same path. Query parameters are preserved for the redirect.
Example
handlers:
- url: /youraccount/.*
  script: accounts.app
  login: required
  secure: always

When a user's HTTPS query is redirected to be an HTTP query, the query parameters are removed from the request. This prevents a user from accidentally submitting query data over a non-secure connection that was intended for a secure connection.

The development web server does not support HTTPS connections. It ignores the secure parameter, so paths intended for use with HTTPS can be tested using regular HTTP connections to the development web server.

To access the versioned appspot.com URL for your application, replace the periods that would usually separate the subdomain components of the URL with the string "-dot-". For instance: https://desired_version-dot-your_app_id.appspot.com/.

Google Accounts sign-in and sign-out are always performed using a secure connection, unrelated to how the application's URLs are configured.

To use custom domains with HTTPS, you must first activate and configure SSL for App Engine with your domain.

static_dir

Optional. The path to the directory containing the static files, from the application root directory. Everything after the end of the matched url pattern is appended to static_dir to form the full path to the requested file.

Each file in the static directory is served using the MIME type that corresponds with its filename extension unless overridden by the directory's mime_type setting. All of the files in the given directory are uploaded as static files, and none of them can be run as scripts.

All files in this directory are uploaded with the application as static files. App Engine stores and serves static files separately from application files. Static files are not available in the application's file system by default. This can be changed by setting the application_readable option to true.

Example:
handlers:
# All URLs beginning with /stylesheets are treated as paths to static files in
# the stylesheets/ directory.
- url: /stylesheets
  static_dir: stylesheets
static_files

Optional. A static file pattern handler associates a URL pattern with paths to static files uploaded with the application. The URL pattern regular expression can define regular expression groupings to be used in the construction of the file path. You can use this instead of static_dir to map to specific files in a directory structure without mapping the entire directory.

Example:
handlers:
# All URLs ending in .gif .png or .jpg are treated as paths to static files in
# the static/ directory. The URL pattern is a regular expression, with a
# grouping that is inserted into the path to the file.
- url: /(.*\.(gif|png|jpg))$
  static_files: static/\1
  upload: static/.*\.(gif|png|jpg)$

App Engine stores and serves static files separately from application files. Static files are not available in the application's file system by default. This can be changed by setting the application_readable option to true.

Static files cannot be the same as application code files. If a static file path matches a path to a script used in a dynamic handler, the script will not be available to the dynamic handler.

upload

Optional. A regular expression that matches the file paths for all files that will be referenced by this handler. This is necessary because the handler cannot determine which files in your application directory correspond with the given url and static_files patterns. Static files are uploaded and handled separately from application files. The example above might use the following upload pattern: archives/(.*)/items/(.*)

url

Required element under handlers. The URL pattern, as a regular expression. The expression can contain groupings that can be referred to in the file path to the script with regular expression back-references. For example, /profile/(.*)/(.*) would match the URL /profile/edit/manager and use edit and manager as the first and second groupings.

The URL pattern has some differences in behavior when used with the following elements:

static_dir
Uses a URL prefix. The regular express pattern should not contain groupings when used with the static_dir element. All URLs that begin with this prefix are handled by this handler, using the portion of the URL after the prefix as part of the file path.
static_files
A static file pattern handler associates a URL pattern with paths to static files uploaded with the application. The URL pattern regular expression can define regular expression groupings to be used in the construction of the file path. You can use this instead of static_dir to map to specific files in a directory structure without mapping the entire directory.

Scaling elements

The following table lists the options for defining how you can specify that your application should scale.

Element Description
automatic_scaling

Optional. Automatic scaling is assumed by default with a default instance class of F1 unless specified otherwise.

The automatic_scaling element sets minimum and maximum levels for number of instances, latency, and concurrent connections for a service.

This element can contain the following elements:

max_concurrent_requests

Optional. The number of concurrent requests an automatic scaling instance can accept before the scheduler spawns a new instance (Default: 8, Maximum: 80).

You might experience increased API latency if this setting is too high. Note that the scheduler might spawn a new instance before the actual maximum number of requests is reached.

max_idle_instances

The maximum number of idle instances that App Engine should maintain for this version. The default value is "automatic." Keep the following in mind:

  • A high maximum reduces the number of idle instances more gradually when load levels return to normal after a spike. This helps your application maintain steady performance through fluctuations in request load, but also raises the number of idle instances (and consequent running costs) during such periods of heavy load.
  • A low maximum keeps running costs lower, but can degrade performance in the face of volatile load levels.

Note: When settling back to normal levels after a load spike, the number of idle instances can temporarily exceed your specified maximum. However, you will not be charged for more instances than the maximum number you've specified.

max_pending_latency

The maximum amount of time that App Engine should allow a request to wait in the pending queue before starting a new instance to handle it. The default value is "30ms".

  • A low maximum means App Engine will start new instances sooner for pending requests, improving performance but raising running costs.
  • A high maximum means users might wait longer for their requests to be served (if there are pending requests and no idle instances to serve them), but your application will cost less to run.
min_idle_instances

The minimum number of idle instances that App Engine should maintain for this version. Only applies to the default version of a service, because other versions are not expected to receive significant traffic. Keep the following in mind:

  • A low minimum helps keep your running costs down during idle periods, but means that fewer instances might be immediately available to respond to a sudden load spike.
  • A high minimum allows you to prime the application for rapid spikes in request load. App Engine keeps the minimum number of “resident instances” running at all times, so an instance is always available to serve an incoming request. You are charged for resident instances, whether or not they are handling requests. For resident instances to function properly, you must be sure that warmup requests are enabled and your application handles warmup requests. The Availability column of the Google Cloud Platform Console Instance page indicates whether an instance is resident or dynamic.

    If you set a minimum number of idle instances, pending latency will have less effect on your application's performance. Because App Engine keeps idle instances in reserve, it is unlikely that requests will enter the pending queue except in exceptionally high load spikes. You will need to test your application and expected traffic volume to determine the ideal number of instances to keep in reserve.

min_pending_latency

The minimum amount of time that App Engine should allow a request to wait in the pending queue before starting a new instance to handle it.

  • A low minimum means requests must spend less time in the pending queue when all existing instances are active. This improves performance but increases the cost of running your application.
  • A high minimum means requests will remain pending longer if all existing instances are active. This lowers running costs but increases the time users must wait for their requests to be served.
Example
application: simple-sample
module: my-service
version: uno
runtime: python27
api_version: 1
instance_class: F2
automatic_scaling:
  min_idle_instances: 5
  max_idle_instances: automatic  # default value
  min_pending_latency: 30ms  # default value
  max_pending_latency: automatic
  max_concurrent_requests: 50
basic_scaling

Optional. The basic_scaling element sets the number of instances for a service.

This element can contain the following elements:

idle_timeout
Optional. The instance will be shut down this amount of time after receiving its last request. The default is 5 minutes.
max_instances
Required. The maximum number of instances for App Engine to create for this service version. This is useful to limit the costs of a service.
Example
application: simple-sample
module: my-service
version: uno
runtime: python27
api_version: 1
instance_class: B8
basic_scaling:
  max_instances: 11
  idle_timeout: 10m
manual_scaling

Optional. The manual_scaling element enables manual scaling for a service and sets the number of instances for a service.

This element can contain the following elements:

instances
The number of instances to assign to the service at the start.
Example
application: simple-sample
module: my-service
version: uno
runtime: python27
api_version: 1
instance_class: B8
manual_scaling:
  instances: 5

Static cache expiration

Unless told otherwise, web proxies and browsers retain files they load from a website for a limited period of time.

You can define a global default cache period for all static file handlers for an application by including the top-level default_expiration element. You can also configure a cache duration for specific static file handlers.

The expiration time will be sent in the Cache-Control and Expires HTTP response headers, and therefore, the files are likely to be cached by the user's browser, as well as by intermediate caching proxy servers such as Internet Service Providers. After a file is transmitted with a given expiration time, there is generally no way to clear it out of intermediate caches, even if the user clears their own browser cache. Re-deploying a new version of the app will not reset any caches. Therefore, if you ever plan to modify a static file, it should have a short (less than one hour) expiration time. In most cases, the default 10-minute expiration time is appropriate.

Send feedback about...

App Engine standard environment for Python