I'm trying to enable html5mode in an Angular 1 application. This mode requires the webserver to return the same HTML for various paths. In nginx, this is done by adding a try ... index.html for the location, meaning nginx always fails back to the main html if it can't find the page.
However, while development I have no nginx, I'm using the Webpack dev server to serve the pages, with a proxy to the backend. How do I configure the Webpack dev server to behave in a similar fashion?
Oh dear. Oh dear oh dear oh dear.
I scanned the documentation twice, and only after posting this question I found the historyApiFallback settings, as described here.
Add this to the settings:
devServer: {
historyApiFallback: true,
proxy: { ... }
}
I'm keeping this question here hoping it will help others save time in the future.
Related
We created a Linux Web App in Microsoft Azure. The application is static written with React (html and Javascript).
We copied the code into the wwwroot folder, but the application only showing only hostingstart.html and when we try to get page index.html we have this error:
Cannot GET /index.html
We tried with a sample of Azure in GitHub (https://github.com/Azure-Samples/html-docs-hello-world) but the error is the same.
The url is this: https://consoleadmin.azurewebsites.net/index.html
Last week the application was running correctly.
We forget to do something?
MAY 2020 - You don't have to add any javascript files or config files anywhere. Let me explain.
I was facing this exact same issue and wasted 6 hours trying everything including the most popular answer to this question. While the accepted answer is a nice workaround (but requires more work than just adding the index.js file), there's something a simpler than that.
You see, when you just deploy an Azure Web App (or App Service as it is also called), two things happen:
The web app by default points to opt/startup/hostingstart.html
It also puts a hostingstart.html in home/site/wwwroot
When you deploy your code, it replaces hostingstart.html in home/site/wwwroot but the app is still pointing to opt/startup/hostingstart.html. If you want to verify this, try deleting opt/startup/hostingstart.html file and your web app will throw a "CANNOT GET/" error.
So how to change the default pointer? It's simpler than it looks:
Go to Configuration tab on your web app and add the following code to startup script:
pm2 serve /home/site/wwwroot --no-daemon
If this web app is a client-side single-page-app and you're having issues with routing, then add --spa to the above command as follows:
pm2 serve /home/site/wwwroot --no-daemon --spa
This will tell the web app to serve wwwroot folder. And that's it.
Image for reference:
Screenshot explaination
PS: If you only set the startup script without deploying your code, it will still show the hostingstart.html because by default that file lies in the wwwroot folder.
Ok you are gonna love this. This happened to me today also. Same exact thing.
I am pretty sure the azure team flipped a switch somewhere and we fell through a crack.
I found this obscure answer with no votes and it did the trick (with a little extra finagling)
BONUS! this also fixed my router issues I was having only on the deployed site (not local):
Credit: #stormwild: Default documents not serving on node web app hosted on Azure
From #stormwild's post see here:
https://blogs.msdn.microsoft.com/waws/2017/09/08/things-you-should-know-web-apps-and-linux/#NodeHome
Steps:
Go to your azure portal, select your app service and launch ssh
In ssh terminal, navigate via command line to /home/site/wwwroot
create index.js there with the following code:
var express = require('express');
var server = express();
var options = {
index: 'index.html'
};
server.use('/', express.static('/home/site/wwwroot', options));
server.listen(process.env.PORT);
NOTE: Be sure to run npm install --save express also in this folder else your app service will crash on startup
Be sure to restart your app service if it doesn't do so automagically
A workaround, I changed the webapp stack to PHP 7
Another solution would be to add a file called ecoysystem.config.js right next to your index.html file.
module.exports = {
apps: [
{
script: "npx serve -s"
}
]
};
This will tell pm2 to associate all requests to index.html as your app service starts up.
Very helpful information here: https://burkeholland.github.io/posts/static-site-azure/
Using Next.js - building this
I am porting my app to the next.js framework. Currently, I am re-creating the authentication system, otherwise, this iteration of my app is pretty bare-bones. All of a sudden, after adding my protected routes (Higher Order Components) - not sure if that is related - I started getting this error along with super clunky loading (obviously).
The connection to http://localhost:3000/_next/webpack-hmr was interrupted while the page was loading.
Otherwise, everything works as expected.
I have no idea how to even begin to troubleshoot this sort of thing. Does anyone have any ideas of how I might get a bit more info/insight on this problem? Guidance on how to debug? My next move is to start disconnecting things until it goes away I guess. Any help would be appreciated! Thanks
As per the resolution suggested in https://github.com/zeit/next.js/issues/9776, You can unregister the service worker if you are using CRA.
The following code shows the way to remove registered service worker:
import { unregister } from './serviceWorker'
// ...
unregister();
If you have already deployed the registered one, first you to need build this code and deploy again it will deploy with unregistered one. The reason for doing this is because the service worker is registered in your users' browsers if you've used register before. unregister removes it entirely, though. If you build you app again, the main JS bundle will get a new hash, the users will download it, and unregister will remove it for them.
Have had the same issue.
I followed recommendations from various sources I researched and none of them worked. In my case it was an issue in next.config.js file.
More specifically, in my next.config.js file I was including an async generateBuildId function but I left it blank in order to revisit the algorithm at a later stage since the project was in its early stage. After returning a valid buildID from this function the warning disappeared.
This usually happens when you are developing the app
The issue might be service work that is getting register to the browser again and again in development mode as the browsers reload fully,
open the Dev tool and check whether a service worker is a registered or not.
if it registers then unregister it, and update your next.config.js so that the service worker will not register again in the browser
I am using "next-pwa" module, below is the check which i have done
pwa: {
disable: process.env.NODE_ENV === 'development',
register: true,
scope: '/',
dest: 'public',
swSrc: 'service-worker.js',
},
My two cents: this happened to me using Firefox, connecting to localhost;
same error:
The connection to http://localhost:9009/__webpack_hmr
was interrupted while the page was loading.
Being specific I was running start-storybook -p 9009 -s public, but that's actually unrelated to the issue.
I solved this clearing Cached Web Content and Site Data at Firefox preferences:
Hoping someone can answer this because I'm struggling...
I have an angular js app that was build with the yo-angular generator. All works fine with deploying through grunt build control, as long as I'm not using the #-free "html5mode."
However, once I enable html5mode to remove the # from my routing and then deploy, my app on github pages doesn't point to the correct source for its scripts and such... For instance, I'm getting a 404 error because it's looking for http://{{user name}}.github.io/scripts/{{name of file}}, instead of http://{{user name}}.github.io/{{app name}}/scripts/{{name of file}}
How can I get it to point to the correct directory?
Hope this makes sense. I'll share more if needed!
You also need to configure the server. The configuration change will depend on what technology you are using to host the app on the server. How to configure your server to work with html5mode
This is in relation to my question about changing node.js configuration in a cordova/ionic application - How to configure node.js routes in a cordova app
I didn't get a satisfactory answer to that. I also had a chat with couple of cordova/ionic guys on their blog, but they mentioned node.js cannot be configured by using express in this case and also did not have any clue to how it can be done.
So, my question is is it at all possible to do something like changing default port or url rewriting in node.js server when working with cordova/ionic applications?
Would love to know what you guys think.
Elaborating more -
Let's say I have a couple of routes like so -
http://localhost:6001/#/home/index
http://localhost:6001/#/content/index
As I didn't want the hash in URL, I added this in my app's config section -
$locationProvider.html5Mode(true);
Which works fine and URLs don't show '#' but on refreshing in browser, now I get this error -
Cannot GET /home/index
This is why I need URL rewriting to be done on server, which I can't seem to figure out.
These are my routes in app.js -
.state('home', {
abstract: true,
url: "/home",
templateUrl: "app/home/home.html"
})
.state('home.index',{
url: "/index",
views: {
"index" : {
templateUrl: "app/home/index.html"
}
}
})
$urlRouterProvider.otherwise('/home/index');
As we discussed in chat, the Cordova_CLI project uses a fixed server for rapid deployment through cordova serve (or ionic serve). This node server does not use express or other plugins to handle routing, it uses a script from the [cordova-lib][1] project.
The script provided for this development server does not take into account URL rewrites, so html5Mode would not work properly without modification of this script. It could be a fork as simple as replacing the do404 function logic to instead set filePath to /index.html.
another option would be running a separate web server (node+express or any other) and including the ionic/cordova scripts in the project.
Ideally, the production app would be running against a public server, and the Cordova_CLI server should only be an issue in dev environments.
I'm trying to push my Angular.js SPA to an IIS7 server but having issues. The application appears to load halfway (as my views and templates are loaded fine), but then stops functioning like so:
As you can see there is no errors in the console...and just for good measure I checked Fiddler which also is having no problems:
The SPA works completely fine on my local web server and only seems to have issues when pushed to IIS. Any thoughts would be greatly appreciated!
EDIT:
Looks like the problem was with angular-csp.css not being properly included when running grunt build -- this was resolved by adding the following to my project's bower.json file:
"overrides": {
"angular": {
"main": [
"angular.js",
"angular-csp.css"
]
}
}
Have you checked the Mime Types on your IIS server? If IIS doesn't know about a particular file type it will often just ignore it.
Also check that you have CORS enabled if you are requesting data from a host other than the one you are deploying to.
Finally, check that you have correctly configured IIS to work with HTML5mode (if you have it enabled. See How to: Configure your server to work with html5Mode
Alright after coming at this with a fresh mind it appears you are correct--everything is working proplery--except my ng-show directives.
Obviously this is because angular-csp.css was not included when running "grunt build."
Since it's not in the angular bower.json main section, I needed to add the following to my projects bower.json:
"overrides": { "angular": { "main": ["angular.js", angular-csp.css"] } }
which fixed the problem.