0

I'm hitting a problem with Tomcat 8.5 when using URL that needs to be encoded. The URL contains [ and ] characters, and those are correctly being encoded as %5B and %5D. I send the request with curl e.g. curl http://somewhere.com/foo%5Bbar%5D but Tomcat throws a 400 error stating that "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).". In the Tomcat access log the URL is report in its decoded form along with the 400 response. I do have an nginx reverse proxy in between, but I don't think that would be decoding the URL. Any ideas what's wrong?

tdudgeon
  • 325
  • 1
  • 2
  • 12
  • Connect to Tomcat directly, to check if it works. NGINX is probably decoding and reencoding the URL (you can add your NGINX proxy configuration to the question). – Piotr P. Karwasz Sep 13 '21 at 10:14
  • Of course you can always work around the problem, by using the [`relaxedPathChars`](https://stackoverflow.com/q/41053653/11748454) connector attribute. – Piotr P. Karwasz Sep 13 '21 at 10:25
  • 1
    Yes, looks like it's nginx that doing the decoding. Need to investigate! – tdudgeon Sep 13 '21 at 16:34
  • Whether NGINX decodes (_"normalizes"_) the URI or not depends on your configuration, see e.g. [this question](https://serverfault.com/q/459369/530633). – Piotr P. Karwasz Sep 13 '21 at 16:59

1 Answers1

2

So it turned out to be a know problem with the nginx ingress in that when it has to rewrite the URL is decodes it and sends the decoded URL downstream to Tomcat which then blows up. There's various discussions on this, but as I needed to fix this as part of the K8S ingress definition I used the info described here. I've not sure where the upstream_balancer thing comes from but must be some black magic, but it does seem to fix the problem. I'm sure there are other approaches that would also work.

tdudgeon
  • 325
  • 1
  • 2
  • 12