Header config causes CLI to throw "invalid rule: cannot contain anything after *"

[ctjlewis]

Describe the bug
The generated _headers file contains a /*/_next/static/chunks/* rule, which throws Error: invalid rule (A path rule cannot contain anything after * token) at line: 1 when netlify dev is run.

next-on-netlify/lib/steps/setupHeaders.js

Lines 22 to 27 in e1f0378

	const staticChunkRule = [
	`/*/_next/static/chunks/*`,
	indentNewLine(`cache-control: public`),
	indentNewLine(`cache-control: max-age=31536000`),
	indentNewLine(`cache-control: immutable`),
	].join("");

This rule is disallowed by the CLI logic:
https://github.com/netlify/cli/blob/425e2c6eeb6a3b589370a78407b18c53f4b850bc/src/utils/headers.js#L65-L73

Does anyone have any suggestions as to how to remedy this?

To Reproduce
Steps to reproduce:

1. Set up project
2. Run next build to build the Next project
3. Run next-on-netlify to build the Netlify output
4. Run netlify dev to start dev server
5. See error

Versions

• Next: v10.0.5
• next-on-netlify: 1.22.5

[ctjlewis]

There is an issue matching this one in the CLI repo. Please let me know if it would be best to add to that thread and I can close this.

netlify/cli#1148

[lindsaylevine]

@ctjlewis thanks for finding this and opening! at first i thought the leading * was necessary because our original syntax wasn't working but that syntax ended up being separate from the *. opening a PR now! <3

[ctjlewis]

@lindsaylevine No worries at all!

Am I right in understanding that this is actually a valid path, and that the CLI should be patched? I started working on a PR in that repo, but I'm not sure if that would be a desirable change (to remove the "cannot contain anything after *" check and add a test to make sure it accepts this path form, /*/.../stuff).

I suppose the real issue at hand there is whether or not this path is actually valid. If it is, we should remove that check. The author of that issue seemed to indicate it was.

Also sorry for spilling CLI questions over into this issue.

[lindsaylevine]

@ctjlewis 🙏

no worries for the CLI questions! happy to help if i can, especially because this is directly related to the issue you opened! that said, you're asking a great question, lol. as evidenced by the several changes i've made now to NoN's _headers logic, it's not exactly my area of expertise. the strange things for me are: 1. the rule/path is respected in and works in production just fine 2. people on the CLI issue you linked claim these rules work just fine if configured in the .toml file. i'd pause that work/PR until you/we can get confirmation on netlify/cli#1148, though i love that you started one already!!!!! i'll be sure to ping people on slack tomorrow about it

[ctjlewis]

It's already pretty much done, so what I will do is send it in as a draft and you guys can edit it if you need, toss it if not. Like you said, it depends on that clarification - if that rule really is allowed, the PR can get merged, and if not, someone might to update documentation / deploy logic.

Anyway, no rush at all, TYSM for your help! Mind if I CC you on that PR draft when I send it?

[lindsaylevine]

@ctjlewis ah okay! sounds good. i just sent this message in slack:

hello! i have a next-on-netlify user who wants to open a PR that addresses netlify/cli#1148. however, he’s/we’re not sure what in this issue is actually considered a valid path and whether it’s safe for him to “remove” this check https://github.com/netlify/cli/blob/425e2c6eeb6a3b589370a78407b18c53f4b850bc/src/utils/headers.js#L65-L73. i’m not entirely sure why these rules seemingly work in production and when configured in .toml files, as the issue commenters suggest. lmk!

feel free to tag me in the PR draft and i'll update my slack message with the PR link!

[lindsaylevine]

@ctjlewis morning! don't see a draft PR from you but here's what my team has said:

Looks like the implementation was based on the docs:
https://github.com/netlify/cli/pull/754#issuecomment-599325288 which don’t have that information, but if it works in production it’s most likely the CLI’s fault.
I would suggest the user to try with the experimental -t  flag (e.g. ntl dev -t) .
That would delegate headers parsing to the traffic mesh local agent.

my teammate that works most on the CLI said you "can open a draft PR fixing the specific use case that doesn't work in the CLI (but works in production) and they'll comment on the PR"!