Headers
Add response headers to matching paths with rules in lahyer.json.
{
"headers": [
{
"source": "/(.*)",
"headers": [
{ "key": "X-Frame-Options", "value": "DENY" },
{ "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" }
]
},
{
"source": "/assets/(.*)",
"headers": [{ "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }]
}
]
}How header rules work
- Every rule whose
sourcematches the path applies, in order. When two rules set the same header, the later one wins. - A rule's header replaces a header of the same name set by your app or by Lahyer, which is how you change caching, for example.
- Rules apply to every response for the path, redirects included.
- Matching ignores letter case and a trailing slash. See path patterns.
Fields
| Field | Description |
|---|---|
source | The path pattern to match. Required. |
headers | 1 to 50 objects, each with a key (the header name) and a value. Required. |
Headers you cannot set
Lahyer manages these, and a rule that sets one fails the build: Connection, Content-Encoding, Content-Length, Host, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailer, Transfer-Encoding and Upgrade. Headers whose names start with x-lahyer- are reserved too.
Values cannot contain line breaks.
Limits
- Up to 100 header rules per deployment, with up to 50 headers each.
- A value up to 4,096 characters.
Headers on a custom domain
A custom domain can carry headers of its own, set from the project's Domains tab. They apply after the rules in lahyer.json, so they win when both set the same header.