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)).

[Frooodle]

Good callout, will switch to jetty in next update

[Frooodle]

Is there any way to force Stirling-PDF to run with HTTPS self signed cert?
there is a custom_settings.yml were you can input your own application settings to override spring ones, which as passing in ssl files etc, there are a few other issue tickets raised with examples around here

[ComprehensiveLuck125]

Hi @Frooodle,
I wanted to say big thank you for switching to Jetty. I am step away from enabling HTTP/2, but how I can actually do that now in simplest manner?
I tried few things but I was not successful (I will try more but wanted to consult you).
It would be great if app was running out of the box using http/1.1 and http2c connector or maybe (better) https/1.1 and h/2 with alpn (self-signed cert).
The best option for me would to run docker container with https and self signed cert.

PS. http2c is actually dead, but haproxy could utilise it when doing SSL offloading if I am not mistaken.
PS2. In logs I have only seen:
2024-06-10 18:13:07,394 INFO o.e.j.s.AbstractConnector [main] Started ServerConnector@aae7c9a{HTTP/1.1, (http/1.1)}{0.0.0.0:8080} 2024-06-10 18:13:07,396 INFO o.s.b.w.e.j.JettyWebServer [main] Jetty started on port 8080 (http/1.1) with context path '/'

[Frooodle]

can you try go to
config/custom_settings.yml and add
server.http2.enabled=true
and see if that works

[ComprehensiveLuck125]

Hello Anthony,

can you try go to config/custom_settings.yml and add server.http2.enabled=true and see if that works

It did not work for me, but maybe I did something wrong (I even repackaged application.properties.yml in app.jar in docker image too, but seen no improvement in logs I am afraid).
I will try more config options, but likely about weekend as I am relatively busy till Friday and have no time :(

I think that SSL config mentioned in other ticket does not work anymore, but I need to try more.

Here is also a helpful comment regarding HTTP2 server: jetty/jetty.project#3204. I will try to pass more info during weekend.

[Frooodle]

Closing this request as initial issue was dealt with,
created #1500 for http2 support so make sure issue is not lost
(I believe we need something our side!)