You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This error is widely documented here.
Please use HTTPS for your reverse proxy, not HTTP as stated in the docs.
You can try to turn on force HTTPS in your config and see if that fixes it.
@JulianPrieber they are using HTTPS in the reverse proxy, but are getting "mixed content" errors because linkstack continues to send HTTP files over HTTPS.
I am the dev of the reverse proxy they are using, how does linkstack decides what protocol to use? May be the proxy is not sending a header that linkstack expects?
LinkStack doesn't really 'decide' on what protocol to use. It simply responds in whatever protocol it's accessed with.
If you access the page over something like proxy_pass http://127.0.0.1:80; all URLs will be generated as HTTP.
Ah so you are deciding depending on the inbound request? Isn't that going to cause an issue with every reverse proxy unless you use HTTPS between the reverse proxy and LinkStack, no? Or may be I misunderstood.
If that's the case, with your answer I am assuming that this is not the first time you see the issue. I am assuming that you have a reason not to use relative path (which would solve the issue already). So one easy solution is to set the links to start with //. If you do this, the browser itself is going to decide whether to use HTTP or HTTPS, so even if Linkstack is served with
User -> HTTPS -> Proxy -> HTTP -> LinkStack
Then the browser will simply use HTTPS to request the files (and the proxy will translate to HTTP)
That's right.
Relative paths aren't currently viable for us. Maybe in the future we can work something out, but as of now we have to let the user use this specific setup to avoid mixed content errors.
Activity
JulianPrieber commentedon May 18, 2023
This error is widely documented here.
Please use HTTPS for your reverse proxy, not HTTP as stated in the docs.
You can try to turn on force HTTPS in your config and see if that fixes it.
zarevskaya commentedon May 18, 2023
Thank you, I check again :)
azukaar commentedon May 18, 2023
@JulianPrieber they are using HTTPS in the reverse proxy, but are getting "mixed content" errors because linkstack continues to send HTTP files over HTTPS.
I am the dev of the reverse proxy they are using, how does linkstack decides what protocol to use? May be the proxy is not sending a header that linkstack expects?
JulianPrieber commentedon May 18, 2023
LinkStack doesn't really 'decide' on what protocol to use. It simply responds in whatever protocol it's accessed with.
If you access the page over something like
proxy_pass http://127.0.0.1:80;all URLs will be generated as HTTP.azukaar commentedon May 18, 2023
Ah so you are deciding depending on the inbound request? Isn't that going to cause an issue with every reverse proxy unless you use HTTPS between the reverse proxy and LinkStack, no? Or may be I misunderstood.
If that's the case, with your answer I am assuming that this is not the first time you see the issue. I am assuming that you have a reason not to use relative path (which would solve the issue already). So one easy solution is to set the links to start with
//. If you do this, the browser itself is going to decide whether to use HTTP or HTTPS, so even if Linkstack is served withUser -> HTTPS -> Proxy -> HTTP -> LinkStack
Then the browser will simply use HTTPS to request the files (and the proxy will translate to HTTP)
Something like
Doc here: http://www.ietf.org/rfc/rfc3986.txt
JulianPrieber commentedon May 18, 2023
That's right.
Relative paths aren't currently viable for us. Maybe in the future we can work something out, but as of now we have to let the user use this specific setup to avoid mixed content errors.
azukaar commentedon May 18, 2023
Note that starting with // are still absolute path, but they will fix your issue for good with mixed contents