Agfdhyk

I have a working Node.js app built with the Express.js framework. All routes in the app are post routes ie.

app.post('/login', function(req, res){

//do login validation

});



app.post('/AppHomepage', function(req, res){

//send user app dashboard

});

etc.

An issue I was having was, if the user had entered an undefined route eg. appdomain.com/thisroutedoesnotexist, they would be returned 'Cannot GET /thisroutedoesnotexist'

I therefore followed the advice in this answer: https://stackoverflow.com/a/25216843 and added

app.get('*', function(req, res) {

res.redirect('/');

});

as the very last route. This works perfectly fine for redirecting undefined requests to the index page and solved the issue.

However, I have found this wildcard redirect is also invoked when LEGITIMATE requests are made. ie. if the user requests /AppHomepage, both

app.post('/AppHomepage', function(req, res){

//send user app dashboard

});

AND

app.get('*', function(req, res) {

res.redirect('/');

});

catches and responds to the request. The user is indeed getting the correct res.render of the homepage, however a console.log inside the index route is also printing meaning that the wildcard route catching the /AppHomepage request even after the app.post('/AppHomepage') route has picked up and served the request.

Can anyone decipher as to why that would be happening?

EDIT:

I know now that even POST requests by the browser will be a GET and that is why the GET wildcard is picking up on the redirects.

My question now is there a way to redirect only undefined requests instead of all GET requests?

If you are testing in the browser all the request by default will be a "GET" request and as you have said all your request is "POST" type so try with postman or other similar api testing tool

[SOLVED]

So the issue was found to be rogue secondary favicon requests by some browsers. The initial defined requests were indeed being picked up the by the respective route handler, however some browsers, such as Google Chrome tend to send secondary favicon requests, separate from the user initiated request and with letting the user know.

This was the request being undefined and picked up by the final wildcard router. Browsers that do not exhibit such rogue behaviour include Apple Safari on macOS and explain why this issue is not 100% reproducible.

Solution is to create an empty favicon router to handle such requests if the request if from a browser that exhibits such non-user initiated behaviour like Google Chrome.