We have an ABP app built using the latest version of ABP - Angular for UI. When running the angular app locally against the .Host hosted in an Azure Web App everything works as it should. However, when pushing the Angular app to a Web App (not a static web app for reasons) everything works as well, except that we always get a "An error has occurred! Error detail not sent by server." at first page load. This regardless of which browser etc. This only happens on first full page load, after which everything works as it should.
There are no errors reported whatsoever in server logs, web browser console etc. If it had not been for this error message, you would have no idea that something isn't what it should be.
This happens regardless of if you are authenticated or now (authentication works fine also).
For obvious reasons we can't post any logs as there are none indicating any problem.
3 Answer(s)
-
0
- This popup is ABP Angular’s global HTTP error handler. On the very first full page load, the Angular UI makes a call to
AbpApplicationConfigurationAppService.GetAsync()(application configuration endpoint). If that call fails (typically 401/403/500 or a blocked request), ABP shows the generic modal “An error has occurred! Error detail not sent by server.”. - In Azure Web App deployments, the most common reason this happens only on the first load is that the very first request from the browser is being redirected or blocked (e.g., HTTP→HTTPS redirect, missing SPA rewrite, missing/incorrect CORS/AllowedHosts, or a proxy/WAF stripping ABP error details). The follow-up request then succeeds (cached config/token/cookies already set), so it “magically” works afterward.
Do the following fixes (they are safe and align with ABP Angular deployment expectations):
Ensure your Angular site serves
index.htmlfor deep links (SPA rewrite)- In Azure Web App (IIS), add/verify a
web.configin your Angular build output (same folder asindex.html) that rewrites all non-file, non-folder routes to/index.html. - Without SPA rewrite, the first navigation can hit a 404/redirect chain and the config call can fail; after you click around (client-side routing), it works.
- In Azure Web App (IIS), add/verify a
Ensure the Angular app’s
environment.prod.tspoints to the correct backend URL (HTTPS)apis.default.urlmust be the exact public URL of your Host (normallyhttps://...).- A common first-load failure is calling the API over
http://(or wrong host) which gets redirected/blocked, while later calls appear fine due to cached baseUrl/config.
If UI and Host are on different origins, fix CORS on the Host
- On the Host, set
App:CorsOriginsto include the Angular Web App origin (e.g.,https://your-angular-site.azurewebsites.net) exactly. - Also ensure
App:RedirectAllowedUrlscontains your Angular URL (important for auth redirects).
- On the Host, set
Verify the first failing request in the browser Network tab
- Reload with “Disable cache” enabled.
- Find the first request that fails (usually the application configuration call).
- Once you see its status code and whether it’s a redirect, you can map it directly to (1)-(3) above. This is the key: the popup is just a symptom of that initial failed HTTP call.
Sources (validated)
- https://abp.io/docs/latest/framework/ui/angular/quick-start
- https://abp.io/community/articles/gjcb2f1e
- https://github.com/abpframework/abp/blob/dev/npm/ng-packs/packages/theme-shared/src/lib/handlers/error.handler.ts
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
- This popup is ABP Angular’s global HTTP error handler. On the very first full page load, the Angular UI makes a call to
-
0
AI response isn't valid as we have no errors and everything works fine except for first page load so should be nothing with CORS etc.
Should add that we are using Azure Web App Linux.
-
0
There are a couple of 204s for
- /openid-configuration,
- /api/abp/application-localization?cultureName=en&onlyDynamics=false
- /.well-known/jwks
- /api/abp/application-configuration?includeLocalizationResources=false
but if those are triggering this, I believe it is the error handling in ABP that is not working as it should as 204s are perfectly valid http codes to get back.
