I've been using zenphoto for years. In 2009, when I started making my own gallery, it was normal to host galleries on standalone servers. But it's already 2019, and I'm trying to keep up with the technology. I try to make zenphoto work as a backend. Haproxy serves as a frontend, it also terminates the SSL connection. Frontend queries go to backend port 80. The browser works over an SSL connection and does not show any errors related to the certificate. However, internal zenphoto scripts generate links to the content inside the pages with the http prefix instead of https, and the browser starts to fill up with mixed content errors. Yes, I know that zenphoto has an https mode, but there is no https on the backend and nothing on port 443. I have never seen such a mechanism in any of the more or less popular CMSs, so I ask for advice. For 10 years I have been a zenphoto match and do not want to switch to another CMS.

I have no idea what Haproxy is. If you enable SSL in Zenphoto's options and the server it is installed on is SSL configured it uses that on front and backend like on our own site and of course generates all links correctly. As you can see on our own site.

If you have static links within text content those are naturally not covered and need to be fixed manually.

Ok, thank you for response. I'll try to fix this.

According to my research, the problem was in the variable FULLWEBPATH. In all plug-ins where it is used, the content of the page includes a full link starting with http. If WEBPATH is substituted instead, the link becomes relative and there is no problem with mixed content.

But I am not a programmer, and I have not found where this variable is assigned a value. To correct all scripts of plug-ins each time at updating is very tiresome. I would like to fix it in one place.

FULLWEBPATH is a core constant that would include the correct protocol depending on the configuration. It is set in zp-core/functions-basic.php on line 283 and depends on another constant set right before it. which uses yet another constant that is set even earlier for the protocol itself

That sounds as if something on your setup with Haproxy might be wrong or Zenphoto is not configured correctly. It is clearly generally working as you can see on our site.

I took a working installation of zenphoto from the work site (standalone, no proxying), made a new virtual host, and placed the files there. It is quite possible that the clean installation did not cause such a problem. Thanks for the advice, I'll try to reinstall it again and see what happens. But, most likely, the problem is in hardcoding full links. For a successful frontend-backend architecture, you still need relative links without specifying the protocol.

URLs Zenphoto generates are not hardcoded as generated dynamically when requested depending on the setting and they need to include the protocol. Hardcoded links would in my understand be something that is inserted into text and does not change in these cases.

Again I have no knowledge about Haproxy but if ZP is called with the proper URLs this issue should not happen.

What is the point of this protocol separation? Why can't relative links be generated in all cases without specifying the protocol explicitly?

Why should Zenphoto generate protocol relative links if the settings tell to use https one? You would have to redirect internally and check everything. If https is set http is not allowed at all and not all servers handle the correct redirection for some reason. It is really not recommended to have protocol relative URLs (especially those protocol agnostic `//domain.com` ones).

It is all working as intended to me and I see no reason to change it. Why can't your proxy setup not use the links as required?

I'm not asking you to change anything. Just curiosity. Anyway, thanks for the support.

Okay, it was not meant to sound harsh or something in case it did. Just trying to understand this proxy setup. I quickly read a bit on the very surface and it seems that Haproxy in general should be able to handle absolute urls.

The problem is in the SSL termination with haproxy. This is my special case of configuration. Without the termination, there would be no problem with absolute links. I will try to explain how it works. Haproxy receives a request for mysite.com. In case it comes via http, an automatic redirection to https is made. Then an SSL handshake is created and a secure connection is established between haproxy and the client. After that haproxy sends the request via http to the backend with the site. The website sends an http page that haproxy encrypts and sends to the client. Apparently, all the troubles begin with the fact that the redirect to haproxy does not work properly, which does not redirect all client requests to https.

Thank you very much for the idea, I will try to improve the redirect conditions.

All right, let us know if you find out anything.