Try to look with the browser’s developer tools (Network tab usually) for the save (asynchronous) request and see what’s the response. If the progress remains at 0% then it means the response is not what the JavaScript code expects. Also check if there are any JavaScript exceptions logged in the JavaScript console.
Hope this helps,
Marius
OK, so my browser doesn’t seem to move on to the resubmission after the 302 response. Am I reading this right? Does this mean it is a client side issue?
302 Response:
This is where the network trace stops:
Check the body/content of the 302 response. I’m pretty sure it follows the redirect, it just doesn’t show it. But the response body should be from the redirect, i.e. the body should come from /rest/jobstatus/…
There is never anything in the body of the 302, even when saving pages not based on templates, which save without a problem. I have just noticed the charset of the 302 response though, shouldn’t this be UTF-8 like all the other responses?
You might have been on to something when you mentioned JavaScript exceptions. I’ve just tried using Chrome to debug instead and I get the following network abort when navigating to almost every page, where spinner.gif is used by java script for page save status visualisation as far as I can tell.
I’ll run this buy a few colleagues and report back if I get any further.
jquery.js:5799 GET https://cdds-wiki.cfdd.org.uk/bin/resources/icons/xwiki/spinner.gif 404 ()
Fa @ jquery.js:5799
css @ jquery.js:6200
get @ jquery.js:6224
css @ jquery.js:6195
(anonymous) @ jquery.js:9754
K @ jquery.js:3643
n.fn.(anonymous function) @ jquery.js:9727
init @ jstree.min.js:2
a.jstree.create @ jstree.min.js:2
(anonymous) @ jstree.min.js:2
each @ jquery.js:365
each @ jquery.js:137
a.fn.jstree @ jstree.min.js:2
(anonymous) @ tree.min.js:1
each @ jquery.js:365
each @ jquery.js:137
m.fn.xtree @ tree.min.js:1
(anonymous) @ tree.min.js:1
execCb @ require.min.js?r=1:29
check @ require.min.js?r=1:18
(anonymous) @ require.min.js?r=1:22
(anonymous) @ require.min.js?r=1:7
(anonymous) @ require.min.js?r=1:23
y @ require.min.js?r=1:6
emit @ require.min.js?r=1:23
check @ require.min.js?r=1:19
(anonymous) @ require.min.js?r=1:22
(anonymous) @ require.min.js?r=1:7
(anonymous) @ require.min.js?r=1:23
y @ require.min.js?r=1:6
emit @ require.min.js?r=1:23
check @ require.min.js?r=1:19
(anonymous) @ require.min.js?r=1:22
(anonymous) @ require.min.js?r=1:7
(anonymous) @ require.min.js?r=1:23
y @ require.min.js?r=1:6
emit @ require.min.js?r=1:23
check @ require.min.js?r=1:19
enable @ require.min.js?r=1:23
init @ require.min.js?r=1:16
I @ require.min.js?r=1:13
completeLoad @ require.min.js?r=1:28
onScriptLoad @ require.min.js?r=1:29
same problem with creating a page from my template
Xwiki 10.8
I’m having the same problem with with my setup:
WIN Server 2012 R2
IIS 8.5 (acting as a reverse proxy)
PostgreSQL 9.6.11
Jetty 9.4.8.v20171121
XWiki 9.11.8
When creating a new page from a custom template I’m keep getting the same error message: Server not responding.
DevTools tells me, that CORS-Header “Access-Control-Allow-Origin” is missing.
I already turned off IIS and even testet access from the localhost.
Then I tried to help myself by editing the web.xml as follows:
<filter-mapping>
<filter-name>Set CORS policy for fonts</filter-name>
<servlet-name>resourceReferenceHandler</servlet-name>
<url-pattern>/*</url-pattern>
<!-- changed line above -->
<url-pattern>*.woff</url-pattern>
<url-pattern>*.eot</url-pattern>
<url-pattern>*.ttf</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
This obviously has an effect but did’t solve the problem. It now tells me, that the token ‘x-prototype-version’ is missing.
How can I set that token? CORS settings from Jetty don’t seem to have an effect.
Screenshots:
I see that you have a JavaScript exception in TaskManagerSheet. This might influence the save operation. Are you creating a task (entry) in the Task Manager application? Can you try to create a page based on a different template? Just to make sure that the problem is not caused by this JavaScript exception.
Hey folks.
I’m seeing the same issue so I dug around a little. I think the problem only exists when running behind a reverse proxy or something alike. I’ve never looked at the xwiki source code before today so the following should be taken with a grain of salt. As far as I can see, something like the following happens:
As soon as you hit “Save and View”, the Page is created just as expected. Next, if this is an async request, the server sends a redirect to the job status resource. This is where things go awry. When the client asks for the job status, the server responds with a JSON indicating the state of the job is FINISHED and provides the link to resource. The problem is that the link provided does neither honor xwiki.home, nor does it honor xwiki.url.protocol. I.e, on my machine, http://127.0.0.1:10010/rest/jobstatus/refactoring/create/1546262584501-56 is returned while the URI should be https://xwiki.sabix.de/rest/jobstatus/refactoring/create/1546262584501-561. This is where the SOP kills the request.
I guess the problem is in JobStatusResourceImpl, where uriInfo.getAbsolutePath() is handed down to create the status or in the function called there, which just calls toString() on the supplied URI.
The thing isn’t a big issue for me. I can always just reload the page. Furthermore, I can probably just configure my apache reverse proxy differently. Nevertheless, I think the server should honor the configuration options in any case. Maybe I’m wrong about that.
I’m sorry that I don’t have time to dig around more right now, but if you have any follow up questions, feel free to ask.
I am having troubles too setting xwiki up behind nginx with SSL, in a docker environment.
None of all the available guides have worked 100% so far. Until now I was too lazy to create another thread…
Chrome warns in the dev console that the response is HTTP for a HTTPS request, the ressource in question is a animated Progress Indication.gif … i guess i should make another attempt.
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.
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.
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
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:
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.
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.
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?