Today I tried adding various HTTP response headers to a Fly app via setting the
services.ports.http_options.response.headers option as described here.
Instead of using a TOML inline table, I defined it as follows for better readability:
[[services.ports]] port = 443 handlers = ["tls", "http"] [services.ports.http_options.response.headers] Content-Security-Policy = "default-src 'self'; base-uri 'self'; form-action 'none'; frame-ancestors 'none'" Referrer-Policy = "strict-origin-when-cross-origin" Strict-Transport-Security = "max-age=63072000; includeSubDomains" X-Content-Type-Options = "nosniff" X-Frame-Options = "DENY"
The above works fine.
But when I define the
Content-Security-Policy key as a multi-line literal string instead of a normal string (again, for better readability), …
Content-Security-Policy = ''' default-src 'self'; base-uri 'self'; form-action 'none'; frame-ancestors 'none '''
…no CSP header is returned anymore after deployment, so there must be some Fly-internal parsing error / incompatibility somewhere.
Defining HTTP response headers with exactly the same syntax (multi-line literal strings that contain semantically irrelevant whitespace) works fine with Netlify (with the
netlify.toml config file to be precise).
Why does Fly fail to process such strings?