reverse proxy support inconsistent and undocumented

[robertmx]

Dear developers,

thank you for working in stirling PDF. Unfortunately the support for reverse proxys is broken and undocumented. The following problems exist:

1. There is no documented way to set the server name and port of sPDF. It is unclear which headers are taken into account and how sPDF determines it's own server name. That results for example in wrong redirects as mentioned in Request to Cancel v2 Redirection for Icons When Using Non-Standard Ports #1113

2. URLs throughout the website are constructed inconsistently. Thus the url base settings are ignored sometimes (for example the apple-touch-icon and the favicon and the bootstrap icons)

It is possible to fix part of these problems with heavy header rewriting and mangling on the reverse proxy. Because the documentation is non-existent, that is a tiresome try-and-error method. I was able to fix problem 1 but not all of problem to with that approach.

That leads me to the conclusion, that the URL routing logic needs consolidation and especially all generated links in the web page need to calculate their values from that central routing information table, which keeps track of the site name(s), port, scheme and uripath.

[Frooodle]

Just to confirm is this in regards to Stirling-PDFs security jar/mode?
I agree the URL redirecting has major issues on security jars side, Do you also mean non security/login mode?

[robertmx]

Hello,

yes i refer to the non-security / non-login mode. I have an identity aware proxy in front who takes care of authentication and authorization.

I think the low-hanging fruit would be to fix the absolute paths in the templates such as these:

`
link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png?v=2"

link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png?v=2"

link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png?v=2"
`

which obviously wont work with some non-root server path. But the bigger problem is sPDF generating some backend-only links with a local address (127.0.0.1) which are impossible to resolve from the client. And the header and location rewriting to fix that is exceptionally ugly.

[Frooodle]

just removing the / should solve that, just merged to develop

[mikebakke]

Sorry to dive in. Will that also fix reverse proxy in secure mode? I am using haproxy and it is unable to load at all presently.

When connecting I get the sign-in screen although the image does not display but entering credentials tells me the server cannot connect. Local mode is absolutely fine - thank you for this utility.

[Frooodle]

No sorry

[mikebakke]

ok thank you - I will try running insecure once the new image drops.

[ComprehensiveLuck125]

I would add 2 things to the discussion. (I am using 0.24.6 docker image).

1. As far as I understand SpringBoot by default uses Tomcat which can either support HTTP/1 (current setup of Stirling-PDF app) or HTTP/2 communication, but not both at the same time. This limitation is causing troubles for some reverse proxies. Actually I am fighting with haproxy setup and can not force Stirling-PDF to work properly.
   I would be very grateful if you could stop using Tomcat as HTTP backend and switch either to Netty or Undertow and enable support for both HTTP/1 and HTTP/2 (https://hackernoon.com/replacing-default-tomcat-server-with-jetty-or-undertow-in-spring-boot-3-a-guide).
2. Is there any way to force Stirling-PDF to run with HTTPS self signed cert? I would like to have ALPN extensions (HTTP/2 / HTTP/1) supported on Stirling-PDF SpringBoot app side. Then I would be sure that my HTTP/1 and HTTP/2 enabled haproxy frontend is able to agree proper communication format with Stirling-PDF backend. (eg. https/1.1 client would agree https/1.1 to speak and https/2 client would speak https/2).
   If docker app could speak both HTTP (1&2) and HTTPS (1&2) with self-signed cert out of the box that would be awesome and super-reverse-proxy friendly!

[ComprehensiveLuck125]

Sorry to dive in. Will that also fix reverse proxy in secure mode? I am using haproxy and it is unable to load at all presently.

When connecting I get the sign-in screen although the image does not display but entering credentials tells me the server cannot connect. Local mode is absolutely fine - thank you for this utility.

You are doing something wrong, because definitely haproxy in my case can load/proxy properly Stirling-PDF via https/1.1. However whatever function of Stirling-PDF I use I usually end up with 404 NOT FOUND error. (something fails on those JSes? Is Stirling-PDF using WebSockets? [that is important to know to me] Can they be disabled somehow?)
When I open Docker-ized app directly, eg. http://dockerhost:8085 then everything works properly. Just I face problem when using Stirling-PDF behind haproxy and Authelia. I do not fully understand what is going wrong.
I would appreciate some help and discussion here if possbile. Hope we can "fix" all problems. (I am running Stirling-PDF without "login-page protection" and with dedicated hostname (root (/) SpringBoot docker context). My Stirling-PDF site is simply protected outside Stirling-PDF app (Authelia used to protect stirling-pdf site)).