RFC: Redirects/rewrites/headers support

Just starting this thread about custom redirects/rewrites/headers support. It seems to be the most requested feature in Next.js 9.5 as of now, so I think it makes sense to support this next.

Next.js docs:

Redirects: https://nextjs.org/docs/api-reference/next.config.js/redirects Rewrites: https://nextjs.org/docs/api-reference/next.config.js/rewrites Headers: https://nextjs.org/docs/api-reference/next.config.js/headers

I am grouping these three features together they are similar and were added at the same time:

• The data for this is stored in routes-manifest.json after Next.js build, so it’s already accessible in the handler code. Note, Next.js does have the regexes stored here as well.
• They all support hardcoded routes + path matching: simple matching, wildcard matching, and regex matching.

Note that there is existing code that I wrote to handle trailing slash redirects (which is not using the default-added redirect in routes-manifest.json right now for perf reasons)

Since we are now using Rollup.js to bundle the handlers, we can write separate files for better maintainability. I suggest the following steps:

• Create a matcher class that will do all matching including simple path matching, wildcard path matching, and regex matching. This code is shared with header/rewrite/redirects and other functionality that may need it in the future.
• Redirects/rewrites: in origin request handler, create new functions/classes to handle rewrites/redirects. For example, for redirects, we would (1) refactor existing trailing slash redirect code into this class, and then (2) add support for custom redirects. Similar for rewrites. These would be done close to the start (e.g replacing the redirect code).
• Headers: create new functions/class to add headers and use it in origin response handler (public files, HTML pages). I don’t believe it’s needed in origin request handler (SSR pages) as you can just set res headers in the page code itself.
• In each of these classes (redirect/rewrite/headers), at a high level, we would:

1. Load routes-manifest.json for the redirects/rewrites/headers list.
2. Check custom paths against the matcher.
3. Do the appropriate action: e.g return redirect response (with correct status code), rewrite the URI, or add a header.

I imagine the tricky part would be the path matching.

I’m already working on the e2e tests, so if someone wants to start on this or has any thoughts on the design, feel free to add your thoughts here. If not, I will work on this sometime later this month.

@danielcondemarin FYI.

[dphang]

The latest alpha should have the fixes for redirects, and also adds rewrites support (except for external URLs are not implemented yet): https://github.com/serverless-nextjs/serverless-next.js/releases/tag/%40sls-next%2Fserverless-component%401.18.0-alpha.2.

Please try it out and open an issue in case of any bugs.

[dphang]

Update: sorry for the delay, I have been busy helping stabilize this component with end-to-end tests and other bug fixes. I will start working on the matcher next (probably this weekend or so)