XWIKI with Apache Tomcat + NGinx Reverse Proxy + UTF-8 Sites not working

Help / Discuss
, ,
1

Hi Guys,

i have a little Problem and i hope maybe someone can help me.

I have a XWIKI Instance with Tomcat 8 and UTF-8 activated.

Some of our Users Created XWIKI Sites with UTF-8 Characters e.g | (Pipe), <, > etc…

If our Users connected to the Tomcat directly all worked fine.

But because of security we created a NGINX Reverseproxy for all our Webapplications and configured XWIKI behind it.

For normal Sites without the special Characters XWIKI works behind the Reverseproxy fine.

But if i will browse a XWIKI-site with a Special Character in it (like | Pipe) thorugh the NGINX-Reverseproxy i getting the following error:

HTTP Status 400 – Bad Request

Type Exception Report

Message Invalid character found in the request target [/x/x/x/x/x/x%C3%A4x%20|%20x:x|x ]. The valid characters are defined in RFC 7230 and RFC 3986

Description The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

Exception

java.lang.IllegalArgumentException: Invalid character found in the request target [/x/x/x/x/x/x%C3%A4x%20|%20x:x|x ]. The valid characters are defined in RFC 7230 and RFC 3986 org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:502) org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:269) org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893) org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1723) org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) java.lang.Thread.run(Thread.java:748)

Note The full stack trace of the root cause is available in the server logs. Apache Tomcat/9.0.48

Thats my config in the Nginx:

  location /x {
    proxy_pass              http://10.254.1.2:8080/x;
    include                /etc/nginx/conf.d/proxy.conf;
  }


 proxy.conf:
> 
> ```
> proxy_http_version                 1.1;
> proxy_cache_bypass                 $http_upgrade;
> 
> ### Proxy headers
> proxy_set_header Upgrade           $http_upgrade;
> proxy_set_header Connection        $connection_upgrade;
> proxy_set_header Host              $host;
> proxy_set_header X-Real-IP         $remote_addr;
> proxy_set_header Forwarded         $proxy_add_forwarded;
> proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
> proxy_set_header X-Forwarded-Proto $scheme;
> proxy_set_header X-Forwarded-Host  $host;
> proxy_set_header X-Forwarded-Port  $server_port;
> 
> ### Proxy timeouts
> proxy_connect_timeout              60s;
> proxy_send_timeout                 60s;
> proxy_read_timeout                 60s;
> ~

Has anyone a clue how i get XWIKI-Sites with a special Character in the URL working through the Reverseproxy?

Thank you very much for your help.

With best regards

Knight01

2

Try adding this to nginx:

http {
    charset utf-8;
}
3

Hi Petarda,

This Part is already present in the NGINX Config.

Have you (or anyone else) another idea?

4

I’ve reread your post. So first of all, pipe is ascii, it’s not utf-8 specific. So it should work even if you don’t activate utf-8.
So you’re saying, you want to have the pipe character in the URL itself? If yes, then you probably cannot and you most definitely shouldn’t. I’ve never seen a pipe in a url before. And the reason for that is written directly in the the error response:

The valid characters are defined in RFC 7230 and RFC 3986

5

Yeah, iám also not Happy with that, but unfortunatelly i must try to find a solution. Especially that has worked for years and makes only Problems if the System is Behind the Reverseproxy. If i contact the Server directly, there is no Problem with the Pipes.

6

Yeah, I’ve no idea how to help. If I were you, I would try to get rid of the pipes. I can only get worse. The fact that it worked for so long doesn’t imply it should continue to work.
Apache, for example, started refusing to accept underscores in the FQDN, because it’s not consistent with the RFC. Nginx still accepts it for some reason. Try another reverse proxy. Who knows, maybe apache does accept pipes :slight_smile: