Handle assets-path correctly

[fraxachun]

If an assets-path to a file that does not exist in the public-folder is called (e.g. /assets/foo) then next tries to render this request and routes to page.tsx. The problem is that the rewrites in the middleware are not executed and "assets" is used as domain-parameter leading to a 500 (instead a desired 404).

This PR handles the assets-path and gets the site-config via the headers so that the 404-page can be rendered.

[nsams]

couldn't you instead avoid the 500 by returning null (instead of throwing Error) and call notFound() in page.tsx if getSiteConfigForDomain returned null?

[fraxachun]

couldn't you instead avoid the 500 by returning null (instead of throwing Error) and call notFound() in page.tsx if getSiteConfigForDomain returned null?

This does not solve the root cause. We normally get the domain from the host (in the middleware) and use it later as domain param. So we can rely on the param to be correct. However, in this special case we skip the middleware so that we have to execute host matching code on a later stage.

Additionally, getSiteConfigForDomain is widely used, allowing to return null requires the consuming part to handle this case. Moreover, when rendering the not-found.tsx we also want to render the according layout.tsx files which themselves use this call.

[johnnyomair]

It's odd that this needs to be done in getSiteConfigForDomain, but I can't think of a better solution. We could try to get rid of the assets folder altogether, as we discussed in #283 (comment).

[johnnyomair]

We should add a comment here explaining why this if is needed.

[fraxachun]

5dcd4c6