Response headers now use list order when more than one rule sets the
same name on a path: the last matching rule wins. New or edited rules
currently move to the top of the Builder list, which would make older
rules override them. Append those rules instead and explain the
precedence in the settings UI. Authentication list behavior is
unchanged.
Validation: SDK response-header tests and typecheck, CLI response-header
tests, SDK build and declaration build passed.
Header rules previously accepted `null` values, which silently turned a
rule into a header-removal instruction even though the settings UI only
offers adding a string value or deleting a rule. Require a nonempty
string throughout the SDK, Builder, CLI generator, and API contract.
Expose configured rules to MCP through `list-response-headers`,
`set-response-header`, and `delete-response-header`. Setting a rule adds
or replaces the header for the same route and case-insensitive name; `/`
and `/*` remain distinct. The Builder UI and MCP operations now share
the same rule-key, edit, and Zod validation logic. The generated JSON
Schema advertises the header-name pattern and nonempty value, while
server-side Zod validation enforces route syntax, forbidden headers,
duplicates, and total size. The generic `update-project-settings`
operation still supports replacing the whole list.
Validation: SDK, project-build runtime and MCP, CLI command and prebuild
tests; SDK, Builder, project-build, CLI, and protocol typechecks; lint,
package boundaries, generated API and docs checks. Local fixture sync
against the development API is blocked by differing bundle versions; PR
CI tests fixtures against its deployed Builder host.
## Description
Project Settings starts with an empty response-header rule list. Users
can add valid HTTP response headers for all paths (`/*`) or an
Authentication-style route such as `/private/*`, and remove any
configured rule. The Headers and Authentication views share the
accessible rule-list form. The header form suggests standard
response-header names and common values for the selected header, while
accepting custom names and values. `Set-Cookie` is not suggested because
a rule can store only one value per header and would replace existing
cookies.
`X-Powered-By`, `X-Content-Type-Options`, and
`Strict-Transport-Security` are dispatcher-owned and cannot be
configured. Users may configure `Content-Security-Policy`,
`X-Frame-Options`, and `Referrer-Policy`; when absent, the dispatcher
supplies their defaults. The SDK validates header names, values, routes,
duplicates, and size limits. The CLI emits only configured rules.
Customization requires Pro for custom-domain publishing, while unchanged
defaults and staging remain available on Free plans. The server checks
the saved production snapshot against the project owner's plan.
Companion Cloud worker PR:
https://github.com/webstudio-is/webstudio-saas/pull/664. Deploy its
dispatcher support before exposing these settings in the Builder. Other
hosts need an adapter that applies the generated rules; Webstudio Cloud
dispatcher defaults do not apply automatically elsewhere. Static exports
do not apply headers automatically.
## Validation
- SDK, CLI, Builder browser, publish-warning, and production-build tests
pass.
- Builder, SDK, and CLI typechecks and lint pass.
- The companion Cloud worker tests, typecheck, and lint pass.
Replaces https://github.com/webstudio-is/webstudio/pull/6428 to use
`headers.staging`.
Closes https://github.com/webstudio-is/webstudio/issues/4748
Oleg Isonen