I have implemented varnish for my web pages.
Now, I have one doubt can i call to Apache server before serving cached content to user
in this case, request flow will be varnish -> nginx ->apache
OR
can i serve varnish from apache level. in this case, request flow will be
nginx -> apache ->varnish
You can set it up any way you want. All depends on your particular requirements.
Typically you would want:
Nginx (for SSL) -> Varnish (caching) -> Apache (for .htaccess)
Related
I have an application that's setup like this:
HAPROXY -> VARNISH -> APACHE (MOD_EVENT) -> PHP_FPM (REDIS + MYSQL)
Haproxy for TLS termination, varnish for cache.
I've enabled http2 in haproxy, varnish and apache:
Haproxy: added alpn h2,http/1.1 to frontend, added proto h2 to backend
Varnish: Added this flag: -p feature=+http2
Apache: installed mod_http2 and added Protocols h2 h2c http/1.1.
What i'm understanding from documentation is that haproxy supports end-to-end http2, varnish only supports http2 on frontend.
So after varnish -> http2 request becomes http 1.1 and apache receives http1.1 requests as I've confirmed through the logs.
My question is:
Should I strive to have end-to-end http2? Is that a desirable thing to do for performance? or should I just not even enable http2 on backend haproxy connection since varnish won't pass it through anyways?
I've been thinking about it for some time.
In theory once HTTP2 connection reaches HAPROXY -> I think we probably wont benefit from HTTP2 multiplexing anymore as the rest of the request travels within datacenter... and network latencies are so much smaller within datacenter right? Just curious if anyone else ran into same question.
The main reason why we use HTTP/2 is to prevent head-of-line blocking. The multiplexing aspect of H2 helps reduce the blocking.
However, when Varnish communicates with the origin server, the goal is to cache the response and avoid sending more requests to the origin.
The fact that HTTP/1 is used between Varnish and the origin shouldn't be a big problem, because Varnish is the only client that is served there. The head-of-line blocking will hardly ever occur.
I'm running in AWS a Ubuntu with a docker server (managed by Portainer) with this two running containers:
1 - NodeRed (Serving my APIs)
2 - Apache (Hosts the site that consumes the APIs from NodeRed above)
I've configured a domain to this server and setted apache to work with SSL. The apache is running ok with my site through HTTPS, but the problem is that the NodeRed (that runs in port 1080) is not configured to run in SSL. This causes a malfunction in my website since that my API endpoints are being running under HTTP and being blocked by the browser due security reasons.
The question is: is there a way to create some kind of "mapping" in apache that receives the request from HTTPS and redirect to the NodeRed in HTTP (the two are running in same server)?
My idea is to create a subdomain like https://api.mysite.com that sends the request for apache and then apache redirects it to my NodeRed. Is that possible?
There is no need to expose the API to the outside world if you don't want to. Since your apache is running correctly and both containers are running on the same host, just use proxy to forward API requests to the API container.
You can achive this by add two lines to your apache config i.e.
ProxyPass /api/ http://127.0.0.1:1080/
ProxyPassReverse /api/ http://127.0.0.1:1080/
I've setup the standard GCP load balancer to point to my instance group. It talks over the same port on the instance. I would like to redirect http to https. I would normally do this in nginx or apache on the instance but that won't work since its https already from the load balancer.
Is there a way to rewrite the url similar to if I was using nginx and apache to load balance in GCP's Load Balancer? or should I forward http and https to the instance and have the instance handle the rewrite as I normally would. I'm new to GCP thanks in advance.
You can set it up the same way as Nginx does. When you see traffic on a port which is not https, you redirect it to HTTPs.
To do this, you can use X-Forwarded-Proto header which contains the protocol using which the traffic came in. On your server, you can simply look for traffic that has http header and upgrade that request to HTTPS.
Most commonly used way is to use 301 redirect, but that is not a great practice. One should use HTTP 426 upgrade request header.
Read more: Is HTTP status code 426 Upgrade Required only meant signal an upgrade to a secure channel is required?
RFC doc: https://www.rfc-editor.org/rfc/rfc2616#section-14.42
It setup wordpress on apache server and config it runs smooth.
Now i want to setup a nginx proxy to server static files.
So i have some questions:
Do i need to duplicate uploads folder of wordpress and put in nginx server ?
Or try to cache all static file in nginx server ?
On apache server i use module deflate, expires, pagespeed, opcache. So if i add nginx proxy to server static files, should i remove the deflate, expires, pagespee module ? Because we can do this work on nginx server.
In case of using Nginx, the Apache HTTPD sever is good but redundant. Nginx can communicate to PHP-FPM directly which is the most efficient solution so far, with that option you can do:
improve performance
simplify deployment procedure
setup gzip and other headers in one place
serve static content more efficiently
reduce amount of overall memory
utilise Nginx cache (with Wordpress plugin to invalidate its cache on page content update)
We have website e.g. http://www.acb.com which points to a hardware load-balancer which is suppose to load-balance two dedicated server. Each server is running apache as a frontend and uses mod_proxy to forward request to tomcat.
Some pages of our website require SSL like https://www.abc.com/login or https://www.abc.com/checkout
SSL is terminated at hardware load-balancer.
When I configured mod_pagespeed it compressed, minimized and merged css file and rewrote them with an absolute url http://www.abc.com/css/merged.pagespeedxxx.css instead of relative url /css/merged.pagespeedxxx.css.
It works fine for non ssl pages but when I navigate to an ssl page such as https://www.abc.com/login all the css and js files are blocked by browser like chrome as their absolute url is not using ssl.
How can I resolve this issue ?
Check for https string in this documentation and this one.
You should show us in your question your current ModPagespeedMapOriginDomain && ModPagespeedDomain settings.
From what I understand from these lines:
The origin_specified_in_html can specify https but the origin_to_fetch_from can only specify http, e.g.
ModPagespeedMapOriginDomain http://localhost https://www.example.com
This directive lets the server accept https requests for www.example.com without requiring a SSL certificate to fetch resources - in fact, this is the only way mod_pagespeed can service https requests as currently it cannot use https to fetch resources. For example, given the above mapping, and assuming Apache is configured for https support, mod_pagespeed will fetch and optimize resources accessed using https://www.example.com, fetching the resources from http://localhost, which can be the same Apache process or a different server process.
And these ones:
mod_pagespeed offers limited support for sites that serve content through https. There are two mechanisms through which mod_pagespeed can be configured to serve https requests:
Use ModPagespeedMapOriginDomain to map the https domain to an http domain.
Use ModPagespeedLoadFromFile to map a locally available directory to the https domain.
The solution would be something like that (or the one with ModPagespeedLoadFromFile)
ModPagespeedMapOriginDomain http://localhost https://www.example.com
BUT, the real problem for you is that apache does not directly receive the HTTPS requests as the hardware load balancer handle it on his own. So the mod-pagespeed output filter does not even know it was requested for an SSL domain. And when it modify the HTML content, applying domain rewrite maybe, it cannot handle the https case.
So... one solution (untested) would be using another virtualhost on the apache server, still HTTP if you want, dedicated to https handling. All https related urls (/login,/checkout,...) would then be redirected to this specific domain name by the hardware load balancer. Let's say http://secure.acb.com. This name is only in use between the load balancer and front apaches (and quite certainly apache should restrict access to this VH to the load balancer only).
Then in these http://secure.acb.com virtualhosts mod_pagespeed would be configured to externally rewrite domains to https://www.example.com. Something like:
ModPagespeedMapOriginDomain http://secure.example.com https://www.example.com
Finally the end user request is https://www.example.com/login, the load balancer manages HTTPS, talk to apache with http://secure.example.com, and page results contains only references to https://www.example.com/* assets. Now when theses assets are requested with an https domain request you still have the problem of serving theses assets. So the hardware load balancer should allow all theses assets url in the https domain and send them to the http://secure.abc.com virtualhosts (or any other static VH).
This sounds like you configured the rewritten URL as http://www.abc.com/css/merged.pagespeedxxx.css yourself - therefor: Try to use a protocol-relative URL, e.g. remove http: and just state //www.abc.com/css/merged.pagespeedxxx.css - this will use the same protocol as the embedding page was requested in.
One of the well standardized but relatively unknown features of URLs