I have currently 3 web server configuration with HAProxy dividing the traffic to one of each web server. Each server is running apache2 with mod_pagespeed. The HAProxy takes care of the SSL termination as the web servers are in local network.
HAProxy sets the X-Forwareded-Proto header to each request and I have enabled "ModPagespeedRespectXForwardedProto on" in each pagespeed configuration.
Apache services are running in custom port 8012 and now I am getting an error to javascript console from pagespeed when going to the site:
Mixed Content: The page at 'https://www.example.com/' was loaded over HTTPS, but requested an insecure script 'http://www.example.com:8012/_,Mjo.NZsywmsdso.js.pagespeed.jm.OLNkjPSHpv.js'. This request has been blocked; the content must be served over HTTPS.
Any idea what could still be wrong? Here is the pagespeed HTTPS configuration:
ModPagespeedFetchFromModSpdy on
ModPagespeedFetchHttps enable
ModPagespeedSslCertDirectory /etc/ssl/certs
ModPagespeedSslCertFile /etc/ssl/certs/cert.pem
ModPagespeedMapOriginDomain "http://www.example.com" "https://www.example.com"
ModPagespeedRespectXForwardedProto on
Any help is appreciated!
This question is old, but I am going to answer how I fix it on my own setup.
The issue comes if you are using pagespeed on each server vs somehow running it on haproxy itself for caching. Since pagespeed saves a copy of any modified file with a modification on filename, then it also changes the source of the HTML to match that new filename it stored, which should work fine. But the issue is that is pagespeed on web server 1 is modifying the HTML to match background compressing of the files(images, js, css, etc) then when it gets to the users computer and their browser requests such files it wont find it if you are round-robin it between servers because that file will be only on web server 1 and not on the others, the way around it is to use a shared folder for the pagespeed so when one compresses a file into that folder, the other web servers will see it through their pagespeed.
Related
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.
I am trying to update the website hosted on my Apache server (running on Fedora Server).
I tried doing both system restart httpd and system reload httpd, but when I open up a web browser and go to the site's IP address, the changes haven't applied. I viewed the source to confirm that the updated code wasn't there, and indeed the updated code was not there.
It seems like the .htaccess was working, it just hadn't "kicked in" yet I guess. I set the max-age to 10 and the updates applied.
I have an Angular2 app that I've been developing for a bit now. Locally I run an Nginx server but the deployment server is using Apache. To unify things I worked to move the deployment server to Nginx but I am getting extremely slow results with Nginx.
Apache loads in ~5 seconds (1.1MB transferred)
Nginx loads in 16-20 seconds (5MB transferred)
These are both on the same server pointing to the exact same directory. The actual size of main.bundle.js is 4470365 main.bundle.js so it seems Nginx is loading the entire file.
How is Apache able to download only 737K?
You can check for the features enabled in both the files with nginx and apache by clicking on the exact file in Inspect element Network Tab. Then go to Headers and then Response Headers as illustrated in the attached image.
Check if the gzip compression is enabled in any one of the server. That is the only reason for lesser file size.
I'm trying to use Liferay for http and https
if I include in portal-ext.properties:
company.security.auth.requires.https=true
web.server.protocol=https
Will be working ok with https but in http is showing incorrect themes due is trying to load https://domain.com/theme
If I remove this two lines is working ok for http but not for https.
What can I do?
IMHO mixed mode, e.g. offering http as well as https never gives you what you expect: You expect security from https, but you always risk leaking session information, e.g. being vulnerable to session-hijacking attacks (ala Firesheep). My actual advice would be to go https only if you do https for security. Read on if that's not an option for you, but don't complain when you find information leaking (this is not dependent on Liferay, but for any web-based environment)
What is the exact problem that you have with the themes? (images/css through http?) Which version of Liferay are you using?
Before you specify more, you might want to configure your theme's "virtual path", this will rewrite all the URLs referring to your theme. It's typically used to serve static resources through a webserver or cdn, but it works with any kind of URL. Simply using a protocol-relative URL should work (I love this mostly unknown http feature):
Add this to your theme's liferay-look-and-feel.xml:
<look-and-feel>
<theme id="my" name="My Theme">
<virtual-path>//domain.com/myTheme</virtual-path>
</theme>
</look-and-feel>
note that the URL omits the protocol part, http: or https:, thus the browser will use the same protocol that the whole page is loaded with.
Edit: corrected the xml. Will investigate if there's a problem with protocol-relative URLs in themes.
Edit 2: Something is weird. It seems, virtual-path does not work like this, but I recall it did earlier. Do you add domain.com as cdn.host.http or cdn.host.https? (this would be concatenated)
On related stuff, please check if you're running Apache in front of your appserver. In this case you might forward some traffic for the portal (e.g. in the virtual host for http) but not forward the traffic in the https virtual host.
When using the basic Tomcat container in Cloudbees, are the static files served by Tomcat or Apache? I need to set the header so browsers do not cache a certain file which would be done in the Apache .htaccess file or I could write a servlet filter for Tomcat to do the same thing.
Cloudbees don't use Apache frontend but nginx. All requests, including static resources, are served by the application container (tomcat, jboss). A best practice is to distribute them on a CDN for better performances and low latency for application users, see http://wiki.cloudbees.com/bin/view/RUN/Using+a+CDN
In my experience all requests arrive at the Tomcat level.
Here is an exempt from my service logs at cloudbees:
11:10:53.031 [http-8841-2] DEBUG o.s.w.s.DispatcherServlet - DispatcherServlet with name 'spring' processing GET request for [/resources/images/logo.png]
Obviously the request for the logo.png file got there.
By the way, I think they use ngineX not Apache.