I have an ember app that I have been building. It has several routes including index (/) and authorization (/authorization). My trouble is that when the application is hosted on hostgator, loading the url myapp.com/authorization results in a 404. This makes sense since there is nothing at that actual url. I need hostgator to redirect all non-file-specific urls to my index.html file.
An example in psuedo code:
if url has extension (.jpg, .pdf, etc)
serve requested url
else
serve index.html but retain url in the address bar
I've done this sort of thing with local instances of node when using AngularJs with ui-router, but this is my first time using History-API based routing served from HostGator.
Any suggestions on where to start to set this up?
Not much of an answer but you can use locationType: 'hash' in environment.js as your configuration.
With locationType set to 'auto', refreshing on application hosted on Hostgator will produce a 404. I have encountered this before and not found any solution. So I switched to 'hash'.
If you find any solution, please tell me. Thanks!
Related
I followed this tutorial on how to host server side generated sites on Google Cloud Buckets. The issue I am having is that the nuxt app works fine when routing internally, but when I reload a route, the site is redirected to whatever route plus a /index.html at the end.
This causes things to break, as it conflicts with Nuxt routing. I set index to be my entry point ala
gsutil web set -m index.html -e 404.html gs://my-static-assets
but it seems to assume that to be the case always. I don't have this problem using Netlify.
According to the tutorial that you're doing, you're redirected to /route/index.html because of your MainPageSuffix index, this means that when you try to access for example https://example.com/route the service look for the target https:// example.com/route/index.html.
To fix this I suggest that you include an index.html file under the subdirectory in the subdirectory of the route.
I recommend, for further info on this to check this post which has a similar issue.
I have deployed a multi-page gatsby site both to AWS Amplify and Netlify.
When I go to a page that doesn't exist on my site that was deployed with Netlify, I get the 404 page I have created. But when I go to the same non-existent route on the site with Amplify, it redirects me to the root path.
I have checked the network tab, and I get a 404 status code without any HTTP redirects. So I assume the redirect happens in the JavaScript code?
Does this happen to anyone else?
Here is the default Rewrites and Redirects for my site on Amplify:
The solution was to change the target address from /index.html to /404.html like this:
I exprienced this same issue, but with all pages reloading to the homepage if they weren't ended with a '/'. Removing all the rewrite rules seemed to fix this for me. I wasn't using any of them and they were set as defaults. Such as 'www' rerouting to '/'.
I have a Vue app that I deployed to was amplify. I noticed that if I click a route it loads but if I refresh that URL the page redirects to an index.html page. Please help if you can.
I solved the issue by going to the rewrite and redirect tabs of amplify and setting .
Since I was using history mode for vue, had to do a rewrite rule.
I set the source address to /<*> , target address to /index.html type to 404(rewrite)
1- try to add a default route at the end of you in your Vue-router to catch everything.
routes: [{ path: '/:pathMatch(.*)', component: main/index/whatever}],
2- add the following rule in your AWS amplify app Rewrites and redirects
/<*> / 200
An ember cli site was deployed onto a server and it works fine. Links via {{link-to}} all work beautifully.
BUT, when a user (me that is) manually enters a url and hits return. then the site is not found.
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
even changing a parameter of a working url (initially navigated to thru link-to)
http://site/start/0/length/30
and simply backspacing, changing the 30 to 20 and hit return
http://site/start/0/length/20
its a no go
localhost:4200 doesn't have this issue.
has anyone observed this vicious behaviour.
i actually need it for a callback redirect for oauth. but then noticed than any manually entered urls dont function.
It is because your server (IIS?) is trying to access the full path requested by your browser (eg /start/0/length/30), and not finding a valid file on disk returns a 404.
So, you need to configure your web server to proxy/rewrite the requests to the proper location. Assuming you are deploying your application in your "root" directory, the proper location is /index.html (the file ember-cli creates).
Unfortunately, I can't help you with IIS, but I can provide you with the proper configuration for nginx:
location / {
try_files $uri $uri/ /index.html;
}
This says "If the requested URI doesn't exist, instead respond with the /index.html file".
When you are using ember server on localhost:4200 you don't have the same problem because it is automatically doing something similar transparently.
If you are serving this up from any web server that isn't the built in Ember, ie non local server, you need to have a wildcard rule that returns your Ember app's index.html file for anything below your websites base url. If you only have your base url return the index.html file, then your webserver is confused by the unrecognized url and thinks it has nothing to return. If your rule, though,
for baseUrl/* returns index.html, your Ember app will then run the correct route hooks to establish the app context
this is a dupe and the question is
How to run emberJS application in IIS?
the easy answer is set locationType: hash in ember-cli's environment.config file (copied from accepted answer)
that will introduce a '#' in the url but doesnt require an IIS change.
var ENV = {
...
locationType: 'hash'
... };
In deploying a version of the Django website I'm working on to Microsoft's Azure service, I added a page which takes a query string like
http://<my_site_name>.azurewebsites.net/security/user/?username=<some_username>&password=<some_password>
However, I was getting 404 responses to this URL. So I turned on Django's Debug flag and the page I get returned said:
Page not found (404)
Request Method: GET
Request URL: http://<my_site_name>.azurewebsites.net/security/user/?username=<some_username>&password=<some_password>?username=<some_username>&password=<some_password>
Using the `URLconf` defined in `<my_project_name>.urls`, Django tried these URL patterns, in this order:
^$
^security/ ^user/$
^account/
^admin/
^api/
The current URL, `security/user/?username=<some_username>&password=<some_password>`, didn't match any of these.
So it seems to be appending the query string onto the end of the url that already has the same query string. I have the site running on my local machine and on an iis server on my internal network which I'm using for staging before pushing to Azure. Neither of these site deployments do this, so this seems to be something specific to Azure.
Is there something I need to set in the Azure website management interface to prevent it from modifying URLs with query strings? Is there something I'm doing wrong with regards to using query strings with Azure?
In speaking to the providers of wfastcgi.py they told me it may be an issue with wfastcgi.py that is causing this problem. While they look into it they gave me a work around that fixes the issue.
Download the latest copy of wfastcgi.py from http://pytools.codeplex.com/releases
In that file find this part of the code:
if 'HTTP_X_ORIGINAL_URL' in record.params:
# We've been re-written for shared FastCGI hosting, send the original URL as the PATH_INFO.
record.params['PATH_INFO'] = record.params['HTTP_X_ORIGINAL_URL']
And add right below it (still part of the if block):
# PATH_INFO is not supposed to include the query parameters, so remove them
record.params['PATH_INFO'] = record.params['PATH_INFO'].split('?')[0]
Then, upload/deploy this modified file to the Azure site (either use the ftp to put it somewhere or add it to your site deployment. I'm deploying it so that if I need to modify it further its versioned and backed up.
In the Azure management page for the site, go to the site's configure page and change the handler mapping to point to the modified wfastcgi.py file and save the configuration.
i.e. my handler used to be the default D:\python27\scripts\wfastcgi.py. Since I deployed my modified file, the handler path is now: D:\home\site\wwwroot\wfastcgi.py
I also restarted the site, but you may not have to.
This modified script should now strip the query string from PATH_INFO, and urls with query strings should work. I'll be using this until I hear from the wfastcgi.py devs that the default wfastcgi.py file in the Python27 install has been fixed/replaced.