We are using react-router-dom v6.
We deployed it using aws s3. Also, when there is an error, I set it to go to index.html. The problem is that when moving like "xxx/admin" within React, there is actually only index.html in s3 (xxx/admin is not present), resulting in an error of 404. After that, when an error occurs, it is redirected to index.html and then called properly.
Please tell me how to get rid of this error. It's hard to find because it's my first aws.
i think before react.js bundle imported, xxx/main request first and error redirect to index.html. when redirect to index.html, js imported so react will render the correct pages. if so, how do i fix this problem.. hard problem to me..
or
I think it's SPA, so only one index.html file exists, but when error occurs, aws s3 called something that doesn't exist file. I want to know the fundamental solution rather than using cloudFront.(redirect error 404 -> 200). plz help me.... I'd appreciate it if you could tell me the reason.
Disclaimer: this is a solution using CloudFront.
In case it might help.
I encountered similar problems when I used react-router-dom v5 & v6. I used BrowserRouter. I deployed the React app directly to S3 without using AWS Amplify. I kept encountering 403 error instead of 404, although I rechecked all my permission settings.
This article helped me eventually: https://blog.nicera.in/2020/08/hosting-react-app-on-s3-cloudfront-with-react-router-404-fix/. And your questions raised here had been discussed and answered in details in this article.
Open up your CloudFront distribution for the React App. In the top tabs, click on Error Pages.
Add the configurations for 403 & 404 as below.
Related
Problem
Noticing when I upload my 'build' content to the server, the md files in docs are breaking.
Not sure why, but there are clearly '.html' files.
But reloading the page doesn't work and i18n doesn't work either.
What confuses me
So, I tried directly accessing the page with '.html' link.
Just to show you,
http://coding-insight.com/docs/python/start/python/ displays 404 when using direct link.
However, using the site's menu bar works.
Reloading results in 404.
But there are clearly html files in the server.
https://user-images.githubusercontent.com/78584173/179334770-46bb6e02-cf6a-4a76-be40-c3fe71038622.png
So, I tried accessing html files directly.
https://coding-insight.com/docs/python/start/python.html
It works. Reloading works.
Question
So, are there any way I could access the html files directly rather than using those '/' at the end?
Is it a bug?
Following a migration, I am trying to reconfigure TYPO3.
The backend is accessible by its url and I manage to connect. But the home page for example gives me the following error: The page did not exist or was inaccessible. Reason: No site configuration found.
All pages are not accessible by their url normally but are accessible through different query parameters, like /index.php?id=2&L=0.
I already tried to replace the .htaccess with the basic one provided by TYPO3, I also checked the Apache configuration and everything seems to be ok. I am not familiar with the TYPO3 CMS so I don't know if some of these configurations are done directly in its files. To me, it seems to be a mod_rewrite problem but I can't find it.
Someone would have a solution or at least a track to solve this problem?
As stated in the error message that you've posted it seems that the site configuration is missing. In the TYPO3 backend you can create new site configuration via Site Management => Sites.
Please check the site handling documentation for details.
I'm migrating to my own VPS with mongoDB after having used Firebase and Firebase hosting.
When on example.com/example, refreshing the page results in a 404 error.
Vue.js documentation says to include this in the caddy file:
try_files {path} /
This prevents the 404 error, but this breaks the api, I guess I somehow need to exclude example.com/api. Does anyone know if this is the case, and what the syntax is?
Also, side question: example.com/api seems to list my entire mongoDB database. Surely this is not desirable, for various reasons? How can I hide this?
I am using React and React Router in my single page web application. Since I'm doing client side rendering, I'd like to serve all of my static files (HTML, CSS, JS) with a CDN. I'm using Amazon S3 to host the files and Amazon CloudFront as the CDN.
When the user requests /css/styles.css, the file exists so S3 serves it.
When the user requests /foo/bar, this is a dynamic URL so S3 adds a hashbang: /#!/foo/bar. This will serve index.html. On my client side I remove the hashbang so my URLs are pretty.
This all works great for 100% of my users.
All static files are served through a CDN
A dynamic URL will be routed to /#!/{...} which serves index.html (my single page application)
My client side removes the hashbang so the URLs are pretty again
The problem
The problem is that Google won't crawl my website. Here's why:
Google requests /
They see a bunch of links, e.g. to /foo/bar
Google requests /foo/bar
They get redirected to /#!/foo/bar (302 Found)
They remove the hashbang and request /
Why is the hashbang being removed? My app works great for 100% of my users so why do I need to redesign it in such a way just to get Google to crawl it properly? It's 2016, just follow the hashbang...
</rant>
Am I doing something wrong? Is there a better way to get S3 to serve index.html when it doesn't recognize the path?
Setting up a node server to handle these paths isn't the correct solution because that defeats the entire purpose of having a CDN.
In this thread Michael Jackson, top contributor to React Router, says "Thankfully hashbang is no longer in widespread use." How would you change my set up to not use the hashbang?
You can also check out this trick. You need to setup cloudfront distribution and then alter 404 behaviour in "Error Pages" section of your distribution. That way you can again domain.com/foo/bar links :)
I know this has been a few months old, but for anyone that came across the same problem, you can simply specify "index.html" as the error document in S3. Error document property can be found under bucket Properties => static Website Hosting => Enable website hosting.
Please keep in mind that, taking this approach means you will be responsible for handling Http errors like 404 in your own application along with other http errors.
The Hash bang is not recommended when you want to make SEO friendly website, even if its indexed in Google, the page will display only a little and thin content.
The best way to do your website is by using the latest trend and techniques which is "Progressive web enhancement" search for it on Google and you will find many articles about it.
Mainly you should do a separate link for each page, and when the user clicks on any page he will be redirected to this page using any effect you want or even if it single page website.
In this case, Google will have a unique link for each page and the user will have the fancy effect and the great UX.
EX:
Contact Us
I have a Joomla site running on Apache and Ubuntu 12.04. I wanted to show a custom 404 pages to be shown when a 404 error occure. I have made necessary changes to error.php file in my template directory to redirect it to '/404' directory where I have an index.html file with many images,css and java script.
Now when accessing a non-existent page, Joomla is redirecting me to root/404 but there I get a 403 Forbidden error from appache. The 404 directory is located inside 'htdocs' directory of Joomla installation.
Additional info:
1. I don't want to convert my 404 page into a Joomla template or article.
2. I am using a Joomla AMI from Bitnami on Amazon web service
If you redirect to a 404 page, you corrupt the error mechanism. The client will never get that 404 status, but a 200 on successful redirect to your error page.
Instead, you should modify your template's error.php to
send the 404 Not Found header
directly send the error page using readfile()
You might have to adjust the asset paths within your error page.
That's totally wrong, working with static pages does not mean that you have to overcome Joomla's routing.
You should either override the error Page view or use custom error pages.
Take a look at Joomla's documentation.http://docs.joomla.org/Custom_error_pages
Nibra was totally right about breaking the mechanism but still using a readfile() seems as an overkill.