Setting Response Headers

For applications with UI, static assets such as HTML, Javascript, css, and images are served by the Content Content Delivery Network through the adobeio-static.net domain. App Builder has supported setting response headers for this static content since aio-cli version 9.3.0.

This feature applies to any App Builder applications with UI, and is helpful for use cases such as:

• Setting CORS Headers to enforce access policies
• Enabling Content Security Policy for assets
• Adding any custom headers required by the application UI

App Builder Developers can now set response headers in the application manifest file - either ext.config.yaml or app.config.yaml - during application development.

The manifest lets headers be set as rules that can select or static assets or paths, or all static assets within the application.

The rules are:

Rules are applied in the order specified in the manifest. For example, rules placed after a given rule can override the previous rule if both apply to the same file.

Once headers are added, they can be deployed with the app using the aio app:deploy command. Note that the paths specified in rules are relative to the distributable folder created after the application build, and not to the application root.

By default, App Builder may set certain response headers automatically for your web actions. If you want to take full control and override all default response headers with your own custom options, you must explicitly opt out of the defaults.

To do this, update your web action with the web-custom-options annotation set to true using the CLI:

Replace <your-action-name> with the name of your web action. This command ensures that only the response headers you define (for example, in your manifest or action code) will be applied, and no additional default headers will be set by App Builder.

This is especially important if you require strict control over CORS, security, or other HTTP headers for your application's endpoints.

Developers may set any HTTP or custom response headers except those in the list below. If the listed headers are specified in the manifest, they will be ignored and not included in the response.

Listed headers are ignored because they are either meant for internal use or are CDN-specific headers that should not be overridden.

1. accept-ranges
2. age
3. allow
4. alt-svc
5. cache-control
6. connection
7. content-length
8. content-type
9. content-disposition
10. content-encoding
11. content-language
12. content-length
13. date
14. etag
15. expires
16. last-modified
17. location
18. server
19. trailer
20. transfer-encoding
21. upgrade
22. x-cache

This concludes the Deployment section.

Return to Deployment Overview.

Return to the Guides Index.