URLs not prefixed with base href after update to Angular 8, breaks i18n

[tuomasi]

🐞 Bug report

Command (mark with an x)

• new
• build
• [ x] serve
• test
• e2e
• generate
• add
• update
• lint
• xi18n
• run
• config
• help
• version
• doc

Is this a regression?

Yes, the previous version in which this bug was not present was: 7.3.9

Description

This is about an application that is German by default but also available in English, French and Italian. On Angular 7, when serving the English version with /en/ as the baseHref value provided in the angular.json configuration, it would automatically prefix every URL with /en/, so that I would redirected e.g. from localhost:8000 to localhost:8000/en. With Angular 8, opening localhost:8000 resuts in a blank page saying Cannot GET /

This bug report is a duplicate of #14925, which was prematurely closed without providing a solution on how to restore the old behaviour and doesn't allow follow-up questions...when introducing such breaking changes, I would expect a proper announcement and an explanation on how to handle the new behaviour. Nothing has been mentioned in the update guide, all related issues have been closed with the issues described being deemed "intended behaviour".

🔬 Minimal Reproduction

You can reproduce the problem by creating a minimal Angular application with the CLI.

ng new angular-i18n-basehref --interactive=false
cd angular-i18n-basehref
ng serve --baseHref=/en/

Then go to http://localhost:8000 instead of http://localhost:8000/en/

Setting "baseHref" in angular.json results in the same out come.

🌍 Your Environment

Angular CLI: 8.3.18
Node: 12.11.1
OS: darwin x64
Angular: 8.2.13
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.803.18
@angular-devkit/build-angular      0.803.18
@angular-devkit/build-optimizer    0.803.18
@angular-devkit/build-webpack      0.803.18
@angular-devkit/core               8.3.18
@angular-devkit/schematics         8.3.18
@angular/cdk                       8.2.3
@angular/cli                       8.3.18
@angular/http                      7.2.15
@angular/material                  8.2.3
@angular/material-moment-adapter   8.2.3
@ngtools/webpack                   8.3.18
@schematics/angular                8.3.18
@schematics/update                 0.803.18
rxjs                               6.5.3
typescript                         3.5.3
webpack                            4.39.2

[clydin]

This issue is actually related to the development server configuration itself and not to the built application. The usage of the HTML base HREF is a function of the browser that occurs at runtime and is not specific to Angular. It is important to note that the built application will work as expected when deployed to a configured production web server as there has been no change in this particular regard between Angular 7 and 8.

The development server is intended to be a basic server that by default does not attempt to, nor can it accurately, mimic the depth and breadth of the potential scenarios possible when deploying to production infrastructure. However, it does provide a set of options which allow some scenarios to be replicated. In this case, by setting the base HREF, the development server (outside of the built application) is using that value as the path to serve the application's files. This results in the application being present at http://localhost:8000/en/. There is nothing being served directly from http://localhost:8000/ by the development server. This has been the case even in versions prior to 8. This is necessary for a functioning application because the browser will combine the base HREF with all relative URL requests.
What has changed is that the history API fallback (which allows path based routing to work with the development server) was errantly redirecting all unknown URL requests to the application's index (e.g., http://localhost:8000/this/should/not/work, http://localhost:8000/api/getdata, or http://localhost:8000/enn). This is incorrect and can result in an application successfully functioning with the development server that would fail when deployed. This also affects both unit and E2E tests as well since they leverage the development server. History API fallback is intended to only redirect URLs that are within the base path of the application. In this case that would be http://localhost:8000/en/.

As the development serve is intended for local development, it is generally recommended to avoid use of any URL modifying application options with its use. These include such options as baseHref and deployUrl. Builds that are intended for deployment to production or production-like (staging/etc.) infrastructure should instead use the appropriate set of options to allow the built application to adapt and function in such a deployed state. However, if it is preferred to use these options with ng serve, the console output will provide the address where the development server is serving the application. For example (note the on http://localhost:8000/en part):

** Angular Live Development Server is listening on localhost:4200, open your browser on http://localhost:8000/en **

The --open option will also open the web browser at the correct address.

[tuomasi]

Thanks for the answer @clydin.

I'm aware of that console message and that I can just open the browser at the "correct" address (localhost:8000/en in the example above), but I will still run into issues when coming back from a third-party site (e.g. for login purposes) because again the /en/ part will be missing and it will say Cannot GET /foo.

Unfortunately, I cannot deduce a solution of how to re-establish the old behaviour from version 7 from your answer - could it be that the old behaviour described in my initial question is just no longer possible on version 8?

Just to give you the complete picture: I have shared some more information in a related SO question https://stackoverflow.com/questions/58839500/angular-cli-8-update-urls-not-prefixed-with-base-href-anymore

[clydin]

Situations like this are actually why the change to the development server was important. Does the setup with the third-party site work when deployed to your production systems? If so, how is the server configured to support the third-party site redirection callbacks to ensure that the correct locale is used? With that information, the development server can most likely be setup via the proxy configuration option to mimic the behavior of the production system.

[tuomasi]

Alright, so I played around some more and it seems that indeed everything is fine.

The one thing we to have to change in our dev workflow (where only one language version is run at a time) is to make sure that both when opening the app and, more crucially, when being redirected back to it from the login service (using a profile's language setting), the language version we're running matches the one the app is trying to redirect us to, since otherwise we'd arrive at Cannot GET abc again, and rightfully so as it turns out. It's just as you said, basically one might say that our app should have not even worked before but still did because the "base href logic was somewhat more forgiving" (for a lack of better words).

Just sharing this in case it could be of help to somebody in a similar situation.

Many thanks for the detailed, insightful and swift replies @clydin 👍

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}