Как заставить Tomcat поддерживать символы, отличные от RFC7230/RFC3986, в параметрах GET?

После обновления версии Tomcat с 7.0 до 8.5 я обнаружил, что если китайские или корейские символы включены в параметры запроса GET, tomcat выдаст исключение IllegalArgumentException: в цели запроса найден недопустимый символ.

org.apache.coyote.http11.Http11Processor service
INFO: Error parsing HTTP request header
 Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
 at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:479)
 at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:684)
 at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
 at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
 at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
 at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 at java.lang.Thread.run(Thread.java:748)

причина в том, что tomcat больше не поддерживает символы, отличные от RFC 7230 и RFC 3986. Мы попробовали несколько решений:

  1. Configure relaxedQueryChars in server.xml according to
<Service name="Catalina">
  <Connector port="10001" protocol="HTTP/1.1"
    connectionTimeout="20000"
    maxThreads="1024"
    minSpareThreads="64"
    redirectPort="8443"
    URIEncoding="UTF-8"
    useBodyEncodingForURI="true"
    maxHttpHeaderSize="65536"
    maxPostSize="-1"
    maxParameterCount="10000"
    bindOnInit="false"
    relaxedPathChars="[ \ ] ^ ` { | }"
    relaxedQueryChars="[ \ ] ^ ` { | }" />

Однако значение может быть любой комбинацией следующих символов: " < > [ \ ] ^ { | }` любые другие символы, присутствующие в значении, будут игнорироваться. Это означает, что китайские/корейские параметры все равно получат ошибку.

  1. Измените клиентскую сторону и закодируйте каждый параметр при запросе API.
    Это может решить проблему, но кажется неосуществимым, поскольку мы не можем изменить всех клиентов, например, выпущенное приложение не может быть модифицированный.

Есть ли хорошее общее решение? Я надеюсь, что смогу изменить некоторые настройки tomcat, чтобы он поддерживал китайские/корейские символы в параметрах GET.


person Alpha    schedule 31.10.2019    source источник
comment
Пожалуйста, обновите свой вопрос, указав некоторые фактические пары имя/значение, которые приводят к IllegalArgumentException, чтобы другие могли попытаться воспроизвести вашу проблему. В Tomcat 9.0.27 я могу воспроизвести IllegalArgumentException с определенными символами, такими как ^ и |, в значении параметра запроса, но китайские и корейские символы у меня работают нормально. Например, myparam=여보세요and你好 отлично работает без каких-либо исключений. (Я неправильно понимаю вашу проблему?)   -  person skomisa    schedule 06.11.2019
comment
Спасибо за ваш ответ. На самом деле ни |, ни myparam=여보세요and你好 не работают на моей стороне. Я использовал версию tomcat 8.5.34, позвольте мне попробовать 9.0.27.   -  person Alpha    schedule 07.11.2019
comment
[1] Хорошо. Я не ожидаю, что | сработает, поэтому просто сосредоточьтесь на значении параметра китайских иероглифов, которое дает вам IllegalArgumentException. Если для вас это не работает с 8.5.34, то я также ожидаю, что это не удастся с 9.0.27. [2] Возможно, в вашей конфигурации есть что добавить/изменить, что исправит это. Можете ли вы обновить свой вопрос, указав достаточно информации о вашем сбое веб-приложения, чтобы другие могли попытаться воспроизвести вашу проблему? [3] Вы можете попробовать использовать браузер Falkon, поскольку он кодирует китайские символы перед их отправкой. Это решит вашу проблему?   -  person skomisa    schedule 07.11.2019