fix(@angular/ssr): remove CSR fallback for invalid hosts

[alan-agius4]

Previously, when a request contained an unrecognized host header, the server would fallback to serving the client-side application (CSR) as a temporary migration path.

This commit removes this fallback behavior. Requests with invalid or unrecognized host headers will now strictly return a 400 Bad Request response.

BREAKING CHANGE: The server no longer falls back to Client-Side Rendering (CSR) when a request fails host validation. Requests with unrecognized headers will now return a 400 Bad Request status code. Users must ensure all valid hosts are correctly configured in the option.

[dgp1130]

LGTM for this change, but at a higher level, I'm a bit worried this could present very breaking behavior for most apps.

IIUC: If a developer doesn't do anything (just ng update), and blindly updates to the next major, they won't get any CI failures or local issues, but upon deploying they will fail all requests. That could catch a lot devs off guard. Is that an accurate assessment of the new behavior?

It's tricky to find a balance which makes this a visible breakage for existing apps while also support new developers creating a new app and not wanting to think about hostnames yet.

Two alternatives I can think of:

1. Validate allowedHosts at startup (maybe limited to production builds?), so the server fails to even start without it. That would hopefully trigger a CI error in most environments and be visible locally.
2. Add some kind of allowEmptyHostsInDev option and enable it automatically in ng new, but then cause a type error for allowedHosts: undefined | [], allowEmptyHostsInDev: false | undefined. This way upgrading apps would get a compile-error that a host needs to be specified while not blocking new apps from dev. Then once we're sure all existing apps have a host listed, we can drop allowEmptyHostsInDev in the next major.

Do either of those options make sense? Is there a path to making this new constraint up front and visible to migrating apps?

[dgp1130]

Consider: Do we still want a separate log statement since we have an unconditionalthrow below? I feel like this would result in double-logging this error under more circumstances.

[alan-agius4]

In this case the throw will be passed to the express error which will not print the message in the console.

[alan-agius4]

Validate allowedHosts at startup (maybe limited to production builds?), so the server fails to even start without it. That would hopefully trigger a CI error in most environments and be visible locally.

This isn't feasible because allowedHosts can be configured through both the options object and environment variables and sense a build failure both during ng build and ng serve is not a possibility.

Add some kind of allowEmptyHostsInDev option and enable it automatically in ng new, but then cause a type error for `allowedHosts: undefined | [], allowEmptyHostsInDev: false | undefined. This way upgrading apps would get a compile-error that a host needs to be specified while not blocking new apps from dev. Then once we're sure all existing apps have a host listed, we can drop allowEmptyHostsInDev in the next major.

Again a build error is not feasible here due to the same thing as described above, in dev-server, we pass the Vite's allowedHost or the provided host that is provided to vite to the SSR engine. A hostname (defaults to localhost) is always needed for the dev-server so the hostname is known. One thing we do not handle is 0.0.0.0 and connecting to the dev-server with external IPs. The dev-server already has an opton --allowed-host which accepts a boolean and disables host checking. I think potentially we could leverage that. I'll try to followup.

[alan-agius4]

This PR was merged into the repository. The changes were merged into the following branches:

• main: 27cd355