The Team that is in charge of ReverseProxy anlysed the logs and said to me :
It seems the page try to call directly Xwiki by server hostname on port 443 (https) https://serv-xwiki.
On the Server where the docker is executed, the Xwiki is not published on port https only on http.
The page is created and we can display it or modified it without any error.
I searched in Wiki config file but i didn’t fond any static URL.
Make sure the xwiki home url and port are configured in the xwiki.cfg to the values you want for your reverse proxy config.
Otherwise when xwiki generates an link it will generate it with its own hostname. When an page is created by a user, xwiki will try to take the user to that url so the user can edit it. This is probably the point and time where the user gets thrown out as the host/domain in the address received from xwiki is different than the host/domain in the url the user accessed.
I guess you need to further diagnose with the browser dev tools - look into the console and log of the browser dev tools.
Back when I started with xwiki and stumbled across the missing home url settings, this is how I figured it out.
For better help you will probably need to post more parts of the xwiki.cfg (just to do we can check and ensure that it’s properly written and not commented or anything), also maybe test to also set the xwiki.url.protocol= setting to https
also the reverse proxy config could potentially be of some importance.
For example new xwiki versions require the reverseproxy to handle websockets for realtime editing. But normally when websockets is not possible it will just fail to start a collaborative editor session.
You could also test with creating an additional apache2 based reverseproxy which uses the config of the xwiki documentation, change the home settings to that one and see if the problem persists.
#---------------------------------------
# URLs
#
#-# The domain name to use when creating URLs to the default wiki. If set, the generated URLs will point to this server
#-# instead of the requested one. It should contain schema, domain and (optional) port, and the trailing /. For example:
#-# xwiki.home=http://www.xwiki.org/
#-# xwiki.home=http://wiki.mycompany.net:8080/
xwiki.home=https://wiki.mydomain.fr/
#-# The name of the default URL factory that should be used.
# xwiki.urlfactory.serviceclass=com.xpn.xwiki.web.XWikiURLFactoryServiceImpl
#-# The default protocol to use when generating an external URL. Can be overwritten in the wiki descriptor ("secure" property).
#-# If not set, the following is used:
#-# * during client request for the current wiki: the protocol from the URL used by the client
#-# * for a different wiki or during background tasks (mails, etc.): information come from the wiki descriptor (also fallback on main wiki)
#-# For example:
#-# xwiki.url.protocol=https
xwiki.url.protocol=https
#-# The name of the webapp to use in the generated URLs. If not specified, the value is extracted from the request URL
#-# and thus it's generally not required to set it. However if you're deploying XWiki as ROOT in your Servlet Container
#-# and you're using XWiki 6.2.8+/6.4.3+/7.0+ you must set it to an empty value as otherwise the code cannot guess it.
#-# Note that not setting this property seemed to work on previous versions when deploying as ROOT but it was actually
#-# leading to errors from time to time, depending on what URL was used when doing the first request on the XWiki
#-# instance.
#-# For example:
#-xwiki.webapppath=
xwiki.webapppath=
I enabled dev tool during create page and i saw that client try to connect on http directly WIKI
