Whenever I add or remove or upgrade an extension, I see this in red at the bottom of the screen.
If I refresh, the task actually works. So it’s not stopping anything - just kind of annoying.
Running XWiki 10.9 on Ubuntu in SSL with NGINX reverse proxy and a Docker container.
Can you check e.g. with the Browser “Developer Tools” -> Network tab which response from the server might cause this behaviour? There should be something in the “XHR” section that returns with a return code different from 200; if it is, it is likely to be the culprit.
The server response of that request might contain an error message that might help to nail down the problem.
I see a 302 error. The requested URL was:
Request URL: https://test.mysite.com/bin/get/XWiki/Extensions
I fixed this by adding the following to the "HTTP Meta Info " under the “Presentation” section of “Look and Feel”
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
For I saw this in the Chrome console:
“This request has been blocked; the content must be served over HTTPS.”
3 Likes
@vmassol . Do you know what file this would need to be hard coded into so that I dont get this error on a fresh install? Im running into this error just trying to install the Standard Flavor during the initialization.
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
Thanks
1 Like
Good Job, thank you.
Hello,
I have the same issue, i can’t upgrade any extention : [Failed to retrieve extension data.Server not responding]
I don’t found the file to add
Anyone can help me to solve this ?
I also got this issue in the distribution wizard. I want to update from 10.9 to 10.10 and in the wizard I want to update the Extensions and that’s the error that is shown.
HI,
12.7.1 has the same problem when installing Standard Flavor at installing /home/dashboard/PanelEntry
So, the install looks like impossible.
What to do?
What exact error do you have? Could you paste the logs?
Maybe there was some connection issue between your server and nexus.xwiki.org? Have you retried?
Thanks
PS: This topic is closed so you may want to open a new one. You can also look at how it was resolved.
In order to help you, you need to provide all the details, and your post is just missing about everything 
- no logs
- no info whether you applied the solution indicated in this post
- no screenshot
Dear Vincent,
thank you for your very fast answer.
know that I did not provide information, because I was a bit disapointed to not find an answer to this problem. (I don’t too much appreciate java, too much talk in dumps).
This said, I found the root cause of this problem. Just that JAVA wants more memory to work.
I had to change CATALINA_OPTS in setenv.sh to make it work.
By the way, I was surprised to see that the code does not manage errors correctly. May I suggest that the first time that something goes wrong during the startup phase, you just stop the execution?
Eg: when connecting first time to database, when xwiki initialize, it would be good to stop immediately if there is an error accessing the database. It would be clearer that just continue to run the code and have KB of dumps…
When there are HTTP 500, suggest to review Xmx settings… (or some timeout settings? or what else?)
And to detect a minimum settings at startup (too old version of tomcat, database, not enough memory…) would be helpfull for most people. To point at the wrong thing at startup.
It’s a few more lines of code, but a lot of stress less for common people installing xwiki. I write a lot of database management shell for my customers and I always try to provide kind of self debug information when something is wrong. It saves a lot of stress and time.
This said, after the hurdle of make it work, I really appreciate xwiki, so I have a few websites using it.
best regards,
Christian
Thank you for the reply @ChristianCOMMARMOND!
Yes I agree, except that XWiki runs in an Application Server (xwiki is a webapp) and XWiki cannot stop the application server All it can do is throw exceptions and this is what it does.
500 just means that there was an error on the server side, it’s not related to memory specifically. There can thousands of problems related to 500.
That would be nice indeed but it’s extremely hard to do. We could do it but it would mean only allowing versions we officially support (see https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/) which means bothering 70%+ of our users. This would remove about a lot of setup that work well with XWiki but that we don’t actively support. You have to understand that it’s the beauty of specifications (and Java in general): XWiki is coded against specs (JDBC, Servlet, etc). So XWiki is not controlling/limiting the softwares used for DB and Servlet Container.
Yes but the job is much harder when you need to make it work with an infinite number of variations!
I appreciate the suggestions and I’m all for making xwiki simpler to setup for admins. This is why we provide fully made distributions where you don’t have to configure anything: the debian one and the docker one are two good examples.
Actually there’s a known limitation with the Debian one about the memory aspect: since Tomcat is installed as a dependency we don’t control its config and by default the memory is too low. We could indeed throw an exception at startup for XS but then that’s risky because depending on the extensions installed, it could work well with the default Tomcat memory. XWiki is not a monolith, it’s a platform where you can add or remove extensions. It’s impossible to know the memory it needs.
May I ask what distribution you’ve used?
Thanks
Hello vmassol,
I have the same issue. The following appears in Chrome console:
Mixed Content: The page at ‘https://kb.tomesto.ru/bin/admin/XWiki/XWikiPreferences?section=XWiki.Extensions&search=Admin+Tools+Application&recommended=false&indexed=true&compatible=true’ was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint ‘http://kb.tomesto.ru/bin/get/XWiki/Extensions?extensionSection=progress&extensionId=org.xwiki.contrib%3Axwiki-application-admintools&extensionVersion=4.4.1&extensionNamespace=wiki%3Axwiki&xback=%2Fbin%2Fadmin%2FXWiki%2FXWikiPreferences%3Fsection%3DXWiki.Extensions%26search%3DAdmin%20Tools%20Application%26recommended%3Dfalse%26indexed%3Dtrue%26compatible%3Dtrue§ion=XWiki.Extensions’. This request has been blocked; the content must be served over HTTPS.
Could you please advise what to do with that?
Hello again, this one I did solve by myself. I just added a connector for https in server.xml. Sorry for bothering.
Late to the party here, but I would argue this is not “resolved”. The OP found a hack way to get around the installation failing. @sfloydt65 asked how to avoid this error during a fresh install here, and 5 years later his question has not been answered, so here I am with the same problem 
So we know that entering a browser’s developer mode and manually adding <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> to the HTML <head></head> tag will allow the install to progress, but how to avoid this error in the first place so this manual edit of HTML in a browser’s developer mode isn’t necesssary? Also, I don’t know much about XWiki at this point, so I don’t know if this is a deeper problem that will pop up later in other aspects of the application, or if it is limited to the installation process. It would be nice to better understand that.
Update 1:
I think I have a good solution to this problem that should prevent it from happening in similar situations with other applications in the future. I’m running XWiki in a Docker container behind an Nginx reverse proxy which is also in a Docker container, so this solution might not apply to everyone. The solution was to add the Content-Security-Policy upgrade-insecure-requests header in 3 places. Here is a minimal example of my Nginx config before applying the solution:
server {
listen 80 default_server;
# Match requests with and with www, and with and without a subdomain
# If a request has a subdomain, it will be stored in the $subdomain variable
server_name ~^(www\.)?(?<subdomain>.+?)?\.?example\.com$;
server_tokens off;
# Redirect all HTTP traffic to HTTPS
location / {
if ($subdomain) {
return 301 "https://$subdomain.example.com$request_uri";
}
return 301 "https://example.com$request_uri";
}
}
server {
listen 443 ssl default_server;
http2 on;
server_name ~^(www\.)?(?<subdomain>.+?)?\.?example\.com$;
server_tokens off;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# Disable TLS 1.0, TLS 1.1, and TLS 1.2 because they are old and insecure
ssl_protocols TLSv1.3;
location / {
set $proxy_pass "";
set $xwiki_container "xwiki";
set $xwiki_subdomain "wiki";
set $xwiki_port "8080";
if ($subdomain = $xwiki_subdomain) {
set $proxy_pass "http://$xwiki_container:$xwiki_port$request_uri";
}
if ($proxy_pass = "") {
return 403;
}
# Proxy the request to the corresponding Docker container based on subdomain
proxy_pass $proxy_pass;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
And after applying the solution:
server {
listen 80 default_server;
# Match requests with and with www, and with and without a subdomain
# If a request has a subdomain, it will be stored in the $subdomain variable
server_name ~^(www\.)?(?<subdomain>.+?)?\.?example\.com$;
server_tokens off;
# For services that write their own URLs and default them to being HTTP, request that they be HTTPS
add_header Content-Security-Policy upgrade-insecure-requests;
# Redirect all HTTP traffic to HTTPS
location / {
if ($subdomain) {
return 301 "https://$subdomain.example.com$request_uri";
}
return 301 "https://example.com$request_uri";
}
}
server {
listen 443 ssl default_server;
http2 on;
server_name ~^(www\.)?(?<subdomain>.+?)?\.?example\.com$;
server_tokens off;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# Disable TLS 1.0, TLS 1.1, and TLS 1.2 because they are old and insecure
ssl_protocols TLSv1.3;
# For services that write their own URLs and default them to being HTTP, request that they be HTTPS
add_header Content-Security-Policy upgrade-insecure-requests;
location / {
set $proxy_pass "";
set $xwiki_container "xwiki";
set $xwiki_subdomain "wiki";
set $xwiki_port "8080";
if ($subdomain = $xwiki_subdomain) {
set $proxy_pass "http://$xwiki_container:$xwiki_port$request_uri";
}
if ($proxy_pass = "") {
return 403;
}
# Proxy the request to the corresponding Docker container based on subdomain
proxy_pass $proxy_pass;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Content-Security-Policy upgrade-insecure-requests;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
}
}
A better solution to this problem I think would be for the Docker image to support defining xwiki.home as an environment variable in the Docker config instead of having to define it in the xwiki.cfg file. Then XWiki should look at the protocol and port used for that environment variable (http/https) and honor it when building URLs.
Optimally all the variables in xwiki.cfg would be exposed as environment variables to Docker 