Page hangs on save (Save 0%...). However, save is successful

#21

Seems like quite a few people are having the same problem. Do we have a clear idea whether this is a bug in xwiki or purely setup issue?

0 Likes

#22

@felher, this could well be the case. Sounds very similar to my experience when operating behind a proxy.

@vmassol, could we have your opinion on this?

0 Likes

#23

My opinion is that this is an issue related to a front end proxy which is either not correctly configured or there’s some incompatibility in XWiki with it. At XWiki SAS we use Apache as a web front end and have never had any such issue. My gut feeling is that the issue is at the proxy config level.

Step 1 would be for someone to list the exact step that should be followed to reproduce the issue (using docker images would be great so that it’s easy to reproduce on developer’s machines).

Thanks

0 Likes

#24

This post seems to give a lof of useful information: https://forum.xwiki.org/t/page-hangs-on-save-save-0-however-save-is-successful/352/19?u=vmassol

Maybe @tmortagne coud check it out since he wrote the async code and job code too?

0 Likes

#25

What is described has nothing to do with async rendering framework or jobs.

The issue seems to be how the absolute redirect URL is resolved and unfortunately this is usually done by the application server (which does not have access xwiki.cfg or wiki descriptors) because we tend to give it relative URL (since that’s allowed in Servlet world) and we should probably not.

See https://jira.xwiki.org/browse/XWIKI-13963.

0 Likes

#26

We have this issue on xwiki.org and it seems to be caused by bad HTTPS setup: relative URLs are being resolved as HTTP even though the current request was made with HTTPS.

0 Likes

#27

FTR and AFAIU this is now fixed on xwiki.org.

0 Likes

#28

After some more research I finally found the cause for the error.

In IIS/ARR I checked the box “Reverse rewrite host in response headers” in order not to expose the XWiki port to the end user.

E.g.: http://intranet.mysite.de/bin/XWiki instead of http://intranet.mysite.de:8080/bin/XWiki

2019-02-12%2010_20_56-vo-intra

The applied rewrite rule itself just routes all requests to http://intranet.mysite.de:8080{UNENCODED_URL}

Any suggestions on how to achieve what I’m doing without “Reverse rewrite host in response headers”? @tmortagne

Maybe also it would be useful to add a short section in the documentation about the topic.

0 Likes

#29

You normally need a “Reverse rewrite” setup in your frontend proxy, as the application server in the backend has no clue what magic happens in the frontend proxy, but just gets the URL the proxy sends to it.

Tomcat seems to allow hardwiring the protocol in the response, but you need to tell it in the server.xml in the <Connector . Adding something like scheme="https" proxyPort="443" redirectPort="443" might help.

Edit: as the docs on xwiki.org propose:

https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/InstallationWAR/InstallationTomcat/#Hhttps28secure29

you are probably better of with an extra <Valve in your <Engine in the tomcats server.xml, like

<Engine name="Catalina" defaultHost="localhost">
  <Valve className="org.apache.catalina.valves.RemoteIpValve"
    internalProxies="127\.0\.[0-1]\.1"
    remoteIpHeader="x-forwarded-for"
    requestAttributesEnabled="true"
    protocolHeader="x-forwarded-proto"
    protocolHeaderHttpsValue="https"/>

Not sure how to do the same thing with other servlet containers like jetty, however.

0 Likes