[[server.headers]]: any way to say "use netlify.toml"?

The new headers section for Hugo 67 https://gohugo.io/getting-started/configuration/#configure-server is really useful, but as it’s compatible with the syntax of netlify.toml, is there a way to avoid duplicate code?

Hey @tdelmas, you can only use netlify.toml… ? :smiley:

1 Like

It’s mostly compatible (their Glob matching library is … not as good as Hugo’s).

That said, there is no way around duplication, 2 reasons for that:

  • The files are different (netlify.toml vs the others)
  • You will likely have server specific values there (locaslhost vs. netlify.com)

The reason I added was that I have on several occasions being doing a “force push and wait for build on Netlify” to debug my security headers … and even with some duplication, this is a big time saver that will make sure you discover these issues before you go into production.

1 Like

I agree, that why I want to use them, because for example CSP are hard to debug. And in that case, the keyword “self” made possible to have identical headers between dev and prod :slightly_smiling_face:

I guess I’ll just add a comment “if you modify here, copy the modification there” in both files!

Thank you for the answer, and for Hugo and it’s awesome features!

1 Like

Note that I guess it could be possible to avoid that duplication … but that would cost more than the 1 hour I spent on adding this. If you keep this in its own file, you could probably script it yourself. But I doubt it’s worth it.

The more generic idea that I had was a toml syntax to say “import that file” or “import a section of that file”

for example:

[menu]=menu.toml to import all menu.toml section under the menu key

[server]=common.toml[server] to import the server section of common.toml section under the server key

[[server.headers]]=netlify.toml[[server.headers]] would be the answer in our case

(no idea yet to say “include all that file here”)

But I think it’s more an issue for https://github.com/toml-lang/toml

Yes, that would be cool. I have one eye on what’s happening in a project called Cue (I think it’s backed by Google) which I have some plan to test out as a data and config format in Hugo, that I would suspect could improve a lot of “this” (whatever “this” is). But that’s not happening tomorrow.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.