Vue.js & Nuxt cache - vue.js

We are hosting a nuxt application with nginx as a reverse proxy and pm2. The application was hosted on domain.com and after a few months transferred to subdomain.domain.com. The domain.com was pointed to completely different server (with apache) and should serve different type of project.
On second server that now holds domain.com, the redirection is made to www.domain.com (Wordpress project).
What started to happen is that if previously visited domain.com, it still shows cached app even tho the domain.com now serves Wordpress project. We though the cache would expire but even after week + it still holds the copy of an app. The server has set redirection from non-www to www.domain.com but that redirection never happens and it still loads app from cache.
So far only if you clear cached data from browser (including service workers) the domain.com loads new project.
Is there a way to force the browser to reload cache?
Thanks.
The headers are set to no cache and non-www domain pointed to completely different server.
The redirection was made from non-www to www and cache was cleared from both servers (Cloudflare)

Related

Record for www Prefix

I have a web app built with Nuxt 3, which I am hosting on Vercel, and a domain that I bought from Google Domains.
I have an A record with domain.com as its hostname, a TTL of one hour, and the IP address from the Vercel dashboard. This works.
However, I did not manage to set up www.domain.com as well. What I currently have (does not work) is a CNAME record with the name * and the value cname.vercel-dns.com. - also taken from the Vercel dashboard. I also tried the value www instead, but both variants simply do nothing. When I try to connect to www.domain.com - even after waiting multiple days to make sure the changes took effect - my browser simply tells me that it cannot connect to this address.

Apache Admin/Manager page lost after adding Virtual Hosts

I wanted to host a couple of websites (and apps) on the same VPS, so my idea was to have it like this:
Site 1
- HTML content only
Site 2
- PHP and HTML content
Site 3
- Java / SpringBoot app
Site 4
- Python app
Site 5
- Java / SpringBoot app
So I got the smallest pack on DigitalOcean, and thought I would start with Apache. Note: I configured the OS already, and tested basic functionality (see more info below)
I installed Apache, configured it to work with my domain (an actual one, not from hosts) and it loaded the basic HTML page. Before I did this, I tested my-domain.com:8080 and it showed the Apache Admin page, all fine. Unfortunately, now after adding my first VirtualHost (and deleting the default one), my Admin page is not accessible anymore (getting a timeout). I also used Let's Encrypt to test how SSL works.
The current state of sites-enabled:
000-default: NOT ENABLED, doesn't work even if enabled
my-domain.com: ENABLED, working with SSL, redirects to SSL by default
my-domain2-from-hosts-file.com: ENABLED, not working, redirects to the default domain
Ideally, I'd like to have a different VirtualHost/domain for each WAR deployed, but let's get the admin/manager page working first.
What could I be doing wrong? I can post logs and config if needed.
Turns out firewall was the one to blame. Port 8080 became blocked after I added Let's Encrypt SSL using their script, so... that's weird.

HTTP access was forced to visit HTTPS

I have a few web sites that are hosted in a VPS.
Today, I found that when visiting "http://api.rsywx.com", it forces me to visit "https://api.rsywx.com", and the redirects me to "https://rsywx.net" (which is SSL enabled).
I checked my virtual host files, and did not find out anything forcing this redirect.
Anyone can point me some direction on how this can happen?
Redirects can be done on different ways and levels. Most elegant ways in descending order (my opinion):
Apache conf (mostly in /etc/apache2/apache2.conf)
.htaccess - file
in the index.php or the used backend script/code
(- could be even done in the frontend with javascript files but for that the page must be loaded and then will be redirected.. So nothing somebody should use)
Problem solved. I added one line in my Silex application's entry index.php to require HTTPS access, which is meant to be locally tested only.

301 Redirect with Reverse Proxy

I am currently struggling to resolve an issue stemming from a reverse proxy. We are running a reverse proxy from page.example.com to example.com/page/ . This original subdomain content is generated from Unbounce.com , and attached to the subdomain.
Problem: We want the subdomain ported to a sub-directory for SEO reasons. The reverse proxy works great, and properly ports the sub-domain, to the sub-directory. Our current issue is that the page.example.com is still getting indexed in Google. We'd like to install 301 redirects to allow only the sub-directory to get indexed. Because we do not have direct access to the content on page.example.com , I cannot put an htaccess file in place to redirect that traffic. Unbounce also charges based on "traffic", and the reverse proxy breaks their tracking information.
They have told us, if we put the 301's in place, their tracking info should push to the new URL structure, and work again.
If anyone could point me in the right direction, that would be fantastic.
Joe

Apache sites do not have http:// prefix in address bar

I've setup 4 sites on a LAMP stack and pointed a number of domains at the server. Everything is running nicely but for some reason, none of the sites have the http:// prefix.
It isn't a massive problem but down-the-line, these sites are going to run https on secure areas and I want visitors to be able to differentiate.
Why would Apache NOT display the http:// prefix? I'm using named virtual hosts and have modified my /etc/hosts file to point the relevant domains to my server's IP.
It's most likely the browser hiding the http:// prefix. It should be happening on every other web site you visit with that browser, too.
You can't control this with Apache - but don't worry, in https mode, the browser will make sure the user sees the difference.