|
| Summary: |
Make XWiki work on Jetty 10.0.3+ without any URI compliance config URIs compatible with Servlet 6 specifications |
| Description: |
Application servers like Jetty and Tomcat started forbidding some special character in the URIs path for a while (leading us to find configuration for them) but the servlet 6 specifications actually made those protections (and more) official. It also made it much more complex to configure Jetty and Tomcat to allow those characters…
So if we want to be good Servlet citizen we need to stop having this kind of URIs.
There are two ways:
* pass those characters through URL parameters instead of path
* forbid those characters on XWiki side too
There is no central place we can easily fix to fix everything, many totally different features in XWiki (and in Contrib extensions) have their own format of URL.
The goal of this issue is to aggregate all those specific features which need to be fixed to have an idea of where we stand in general on this subject:
See also XWIKI-19081
In order to not have to configure jetty with {{jetty.httpConfig.uriCompliance=RFC3986}} we would need to fix all places in XWiki where URL path elements can contain the % symbol (which gets encoded as %25)
Some examples:
* Various APIs manipulating Space/Doc names - For this we could forbid the % characters in page names by default, same as we do for / and \ for Tomcat
* Async job REST API which take double encoded ids in input. Thus, any character in the job id that contains characters that are special URL characters ({{: / ? # [ ] @ ! $ & ' ( ) * + , ; =}}) are url-encoded, leading to % being used, which then is encoded as %25 and triggers the Jetty URL compliance check. For example, if the async macro is used on a page that contains any of these characters.
* Generic Job REST API when the id contains a %. While nothing prevent it, it currently tends to be rare in XWiki Standard except for jobs related to pages which reference contains a % (which could be fixed by a general embargo on % in pages references as described in a previous point) and async rendering jobs (which are currently generally manipulated through a dedicated API, but it would affect XWIKI-16666) but that could change with new kind of jobs.
* <add other places here>
|
|
