Skip to content

[Bug]: Header rules in 'next.config.js' not observed for root route when statically built and using localized routing #1883

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
2 tasks
SmartyP opened this issue Jan 13, 2023 · 2 comments · Fixed by #1893
Assignees
Labels
type: bug code to address defects in shipped code

Comments

@SmartyP
Copy link

SmartyP commented Jan 13, 2023

Summary

In NextJS you can configure customized headers for matching routes by having something like this in your next.config.js:

headers: async () => {
	return [
		{
			source: '/:path*',
			headers: [
				{
					key: 'X-Content-Type-Options',
					value: 'nosniff',
				},
			],
		},
	];
},

In this example, the source /:path* is meant to include all potential routes. We are finding one specific scenario where the root route (/) is not affected by these custom header rules - but all other page routes are returning the headers properly.

Specifically, we are finding that when using localization and localized routes, this rule in next.config.js above turns into the following rule in the netlify.toml:

[[headers]]
for = "/:nextInternalLocale(en\\-US|fr|de)/*"

  [headers.values]
  X-Content-Type-Options = "nosniff"

And apparently this /:nextInternalLocale(en\\-US|fr|de)/* does not include the root route (/). When not using localization, the same rule above instead turns into this:

[[headers]]
for = "/*"

  [headers.values]
  X-Content-Type-Options = "nosniff"

Which does include the root route.

So for now, in order to have the root route covered by custom header rules, we have to also setup the same rules in the netlify.toml file explicitly for the root route. Ideally this should be unnecessary and the root route should be covered by the next.config.js wildcard as occurs when not using localization.

Side note - we had tried defining an additional explicit root route (/) in the next.config.js, but that did not seem to have an effect. This was the next.config.js:

headers: async () => {
	return [
		{
			source: '/:path*',
			headers: securityHeaders,
		},
		{
			source: '/',
			headers: securityHeaders,
		}
	];
},

.. and this was the netlify.toml output:

[[headers]]
for = "/:nextInternalLocale(en\\-US|fr|de)/*"

  [headers.values]
  X-Content-Type-Options = "nosniff"

[[headers]]
for = "/:nextInternalLocale(en\\-US|fr|de)"

  [headers.values]
  X-Content-Type-Options = "nosniff"

Note that it still injected the /:nextInternalLocale(en\\-US|fr|de) part, which apparently makes it not match the root route (/).

Steps to reproduce

Please see the following Netlify support ticket:
https://netlify.zendesk.com/agent/tickets/126167

In that ticket will be a link to a test site where you can test all pages of the site and get the proper headers (as defined in the next.config.js), except for the root route, which will instead return a different set of headers (as defined in the netlify.toml). Also can provide access to a sample code repo through that ticket.

A link to a reproduction repository

No response

Next Runtime version

12.1.0

More information about your build

  • I am building using the CLI
  • I am building using file-based configuration (netlify.toml)

What OS are you using?

None

Your netlify.toml file

`netlify.toml`
# Paste content of your `netlify.toml` file here

Your public/_redirects file

`_redirects`
# Paste content of your `_redirects` file here

Your next.config.js file

`next.config.js`
# Paste content of your `next.config.js` file here. Check there is no private info in there.

Builds logs (or link to your logs)

Build logs
# Paste logs here

Function logs

Function logs
# Paste logs here

.next JSON files

generated .next JSON files
# Paste file contents here. Please check there isn't any private info in them
# You can either build locally, or download the deploy from Netlify by clicking the arrow next to the deploy time.
@SmartyP SmartyP added the type: bug code to address defects in shipped code label Jan 13, 2023
@kodiakhq kodiakhq bot closed this as completed in #1893 Jan 24, 2023
@orinokai
Copy link
Contributor

Thanks for reporting this issue! Fix due for release in v4.30.2.

@SmartyP
Copy link
Author

SmartyP commented Mar 27, 2023

Thank y'all, this fix worked great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug code to address defects in shipped code
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants