Url in attachments containing port 80

Hello,

XWIKI is used behing haproxy, haproxy terminates SSL and forward everything to port 8080.

File can be uploades to pages and subpages.

But can’t be deleted or browsed from pages anymore because automatically port 80 is added.

eg.: (https://myfqdn:80/xwiki/bin/download/…)

If I check the attachemnts under

Page index → Attachments the URL is ok and the files can be downloaded.

What could be the reason. The latest Version 15.1 is running.

1 Like

Workaround for this issue was to set the port in “host” header.

After the port 443 was included everything was working like expected.

1 Like

If I understand your problem correctly, it can also be solved by setting

xwiki.home=https://yourdomain/

in xwiki.cfg.

This issue with the added port 80 seems to have been floating around for quite a while now. I have not seen a true solution to it. Yes I also suffer from this problem. I have tried the suggested remedies from various posts to no avail. In my case the port 80 is added to the URL of the Wiki’s in the Wiki Index (haven’t checked elsewhere).

What options are left?

I’m running the latest Xwiki 15.10.4 docker instance behind a nginxpromanager.

As @baumannt wrote:
Adding :443 to the host header solves this. In nginx this would be:
proxy_set_header Host xwiki.yourdomain.com:443;
hth

1 Like

Thanks for the reply @baumannt Your answer prompted me to look again and then I discovered I had edited a xwiki.cfg file in a different volume from an old installation.

I implemented:

xwiki.home=https://wiki.mydomain.com/
xwiki.url.protocol=https

which worked!

It worked for me as well! Do you understand why does it work? Thanks!

As far as I understood it back when I was testing Realtime Editing behind a reverse proxy, home and protocol URL configuration tells XWiki / the application server on which protocol to “send out” stuff. (Link: Realtime WYSIWYG behind reverse proxy - #9 by TomTheWise)

When not set, you still can access XWiki on https / port 443 when the reverse proxy is configured even though XWiki home and URL are http / port 80 by default. But when XWiki initiates a download or similar its not an “answer” but rather a “send” to the client and then it is sending it over its default protocol / port.
That is why these two parameters in the config are important. As the XWiki is behind a reverse proxy, it is probably not possible / not easy to replace that two configurations with some kind of automatism.

It could be, that my understanding of this is not 100% precise, so take it with a grain of salt. But its something in that general direction.

1 Like

@TomTheWise, thanks for taking time to reply. I recognize that it is a bit of too much for me to understand it so far.

The funny thing is that URLs changes from https to http not when I click on a link, but when the page is composed: when I click Attachments tab, URL changes to http. As you said, it is the only place in the page where a download action is available. I could download the file, but not delete the attachment. As in other cases in this forum, copy/pasting the address and changing http to https, does work.

It is clear to me that I need to understand how the WWW does work! I will keep studying!

Thanks!