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

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?

@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?

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

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?

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.

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.

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

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.

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.

1 Like

I tried several configurations but it ultimately boils down to the fact that I’m using IIS as a SSL-Proxy and for some URL-Rewriting. Thus the XMLHttpRequest returns an answer from an non-SSL URL since my instance of Jetty is not configured to use SSL. The browser then immediately blocks the request from prototype.js as being unsecure mixed content.

2019-05-08%2014_00_41-Window

According to the CORS specification it is possible to make requests from http to https but no way to do it the other round which makes sense. In other words JavaScript will make the call with the same protocol that the page was loaded. In my case the best solution is probably to configure Jetty to use SSL.

There is one thing that puzzles me, though. The error affects all templates except for the empty one. Does the empty template use a different mechanism to create the page?

It should be fixed with https://jira.xwiki.org/browse/XWIKI-16160