Hello all,
in the new image picker the links to the previews are missing an /WebHome/. Any Idea where to look for a solution?
In the picture below I added the /WebHome/ and voilà, the image is shown.
Regards, Johannes
Hello @jwielsch ,
We have identified a similar bug related to a regression related to jetty (the WebHome segment is supposed to be optional).
To confirm you are hitting the same bug, can you tell me what’s your XWiki version as well as your application server?
Thanks
I tried with XWiki 14.10.1 and tomcat (using the xwiki:14.10.2-postgres-tomcat), and I couldn’t reproduce.
My understanding is that the issue is caused by a configuration issue on the tomcat side.
To confirm this, could you check your browser’s dev tool and tell me if the network request to your images return an error?
I get an 404 repsonse, beacuse “WebHome” is missing at the marked position.
Hello,
we encountered the same Bug and it is still present after upgrading to xwiki 15.2.
We run xwiki (xwiki-tomcat9-mariadb/stable) on Debian 11 so at the moment we have
- tomcat 9.0.43
- openjdk 11.0.18
- apache 2.4.56 as reverse proxy
Any suggestions for further debugging?
Thanks in advance
Coud you share your configuration for the reverse proxy and whether you’ve configured short urls too?
Hi @vmassol. We do not use short urls. Here is our Apache Config:
<VirtualHost xxxx:80>
ErrorLog ${APACHE_LOG_DIR}/error.log
# CustomLog ${APACHE_LOG_DIR}/access.log combined
ServerName wiki.xxx.de
ServerAlias *.wiki.xxx.de
ProxyPreserveHost On
ProxyPass "/websocket/" "ws://localhost:8080/websocket/"
ProxyPass "/" "ajp://localhost:8009/"
ProxyPassReverse "/" "ajp://localhost:8009/"
<IfModule !mod_auth_kerb.c>
LoadModule auth_kerb_module /usr/lib/apache2/modules/mod_auth_kerb.so
</IfModule>
<Location "/">
AuthType Kerberos
AuthName "Wiki von xxx"
KrbMethodNegotiate on
KrbSaveCredentials on
KrbMethodK5Passwd off
KrbAuthoritative on
KrbLocalUserMapping on
KrbAuthRealms xxx.INT
KrbServiceName HTTP/wiki.xxx.de@xxx.INT
Krb5Keytab /etc/apache2/ssl/xxx.keytab
KrbVerifyKDC off
require valid-user
Header always merge Access-Control-Allow-Origin '*'
</Location>
ErrorDocument 400 /var/www/html/errors/400.html
ErrorDocument 500 /var/www/html/errors/500.html
ErrorDocument 502 /var/www/html/errors/502.html
ErrorDocument 503 /var/www/html/errors/503.html
ErrorDocument 504 /var/www/html/errors/504.html
</VirtualHost>
FTR, I also get an empty URL path (and that needs to be fixed), but I get the image displayed. For example on XWiki 15.2:
So the issue is that for some reason, on your Servlet container, the following URL (for example) is not working (you can try it):
http://localhost:8080/xwiki/bin/download/Help/Applications//meeting.png?width=150&height=150
FWIW, I’ve re-tested with Tomcat 9.0.43 and Tomcat 9.0.73 and it worked fine.
Note that the reason why we get // is because of xwiki-platform/xwiki.js at 4c175405faa0e62437df397811c7526dfc0fbae7 · xwiki/xwiki-platform · GitHub
So this should happen for all code that calls getURL() (and there are quite a lot of places doing that).
In any case, this should work fine so there must be something on your side that makes Tomcat fail to load a URL with //.
I’ve tried with subwikis (both with path-based and domain-based), and it worked fine too.
1 Like
I’m not a dev, so I can’t fully understand the following discussion, but it seems that there has indeed been a change in Tomcat:
Re: Double Slash Support in Tomcat 9.0.27
2019-11-29 Thread M. Manna
HI,
On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal
wrote:
> Hi,
>
> We are working on upgrading our enterprise application from 8.5.24 to
> 9.0.27 version.
>
> What we have observed that in earlier version i.e. 8.5.24 we were able to
> process process a REST URI have double slash ("//") in it.
>
> But when we are upgrading it to 9.0.27 we found that now the same url which
> was working earlier it is now throwing 404 status code.
>
> Now, the problem is that we can not remove these double slash (//) manually
> as it is used widely.
>
> So, can someone please provide a possible solution of this issue?
>
Tomcat processes HTTP query and URL using RFC 7230 standards. But multiple
leading forward slash support was disabled by default for good reasons.
This was done in 8.5.31 due to issues with Http Redirects involving
Servlets.
If you must use this, you have to modify your application context to add
the override as true - the attribute is called
"allowMultipleLeadingForwardSlashInPath".
https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
But I would sincerely recommend that you work on such designs and correct
them in your application. There is always a "way". This is one of the
reasons web applications become obsolete requires huge maintenance.
Thanks,
>
> --
> Regards,
> Kushagra Bindal
> +91-9013792807
>
At the End of: subject:“Re: Double Slash Support in Tomcat 9.0.27” (mail-archive.com)
Is that discusison related to the problem?
Indeed, this seems like the issue. It’s still true in Tomcat 9 (Apache Tomcat 9 Configuration Reference (9.0.73) - The Context Container).
What I don’t understand ATM is why it works for me when I try XWiki on Tomcat 9. I’ve checked and we don’t set allowMultipleLeadingForwardSlashInPath (we provide a context.xmlfor Tomcat but we don’t set it there by default).
Could you try to set it to true on your side to see if it works?
Thanks
EDIT: once confirmed, I’ll update Tomcat Installation (XWiki.org)
EDIT2: I’ve created Loading...
I’ll do soon and come back here afterwards.
I added it this way. Is it correct?
<Context allowMultipleLeadingForwardSlashInPath="true" containerSciFilter="org.apache.jasper.servlet.JasperInitializer">
<JarScanner>
<JarScanFilter defaultTldScan="false"/>
</JarScanner>
<!-- We need to set the resource cache size since the default (10K) is too small for loading all XWiki resources at
once -->
<Resources cacheMaxSize="50176" />
</Context>
If the code is correct, then this did not help, as thumbnails are still not shown.
That looks like what I would have expected. Where did you make that change (to be sure that the file you’ve modified is being used)?
Hello and sorry for my late feedback!
Setting allowMultipleLeadingForwardSlashInPath has no effect on our side.
- we don’t use short urls
- our setup is based on the context configuration of the debian package. We changed the path from
/xwikito/abc
/var/lib/tomcat9/conf/Catalina/localhost/abc.xml
<Context docBase="/usr/lib/xwiki" containerSciFilter="org.apache.jasper.servlet.JasperInitializer" allowMultipleLeadingForwardSlashInPath="true">
<Resources allowLinking="true" cachingAllowed="true" cacheMaxSize="50176"/>
<!-- Disable JAR scanning since XWiki does not need that -->
<JarScanner scanClassPath="false">
<JarScanFilter defaultTldScan="false"/>
</JarScanner>
</Context>
Nothing special in our apache config:
<VirtualHost *:443>
ServerAdmin ...
ServerName ...
DocumentRoot /var/www/html
<Location /abc>
ProxyPass "http://localhost:8080/abc"
ProxyPassReverse "http://localhost:8080/abc"
<RequireAny>
...
</RequireAny>
</Location>
...
Hi @vmassol. I am sorry for the late reply. I added the parameter here: /usr/lib/xwiki/META-INF/context.xml