Exception: Invalid character found in the request target. The valid characters is defined in RFC 3986

The request parameter contains special characters when the background report this error:

Info: Error parsing HTTP Request Header
Note:further occurrences of HTTP header parsing errors'll be logged at DEBUG level.
Java.lang.IllegalArgumentException:Invalid character found in the request target. The valid characters is defined in RFC 7230 and RFC 3986
At Org.apache.coyote.http11.InternalAprInputBuffer.parseRequestLine (internalaprinputbuffer.java:235)
At Org.apache.coyote.http11.AbstractHttp11Processor.process (abstracthttp11processor.java:1000)
At Org.apache.coyote.abstractprotocol$abstractconnectionhandler.process (abstractprotocol.java:637)
At Org.apache.tomcat.util.net.aprendpoint$socketprocessor.dorun (aprendpoint.java:2517)
At Org.apache.tomcat.util.net.aprendpoint$socketprocessor.run (aprendpoint.java:2506)
At Java.util.concurrent.ThreadPoolExecutor.runWorker (threadpoolexecutor.java:1145)
At Java.util.concurrent.threadpoolexecutor$worker.run (threadpoolexecutor.java:615)
At Org.apache.tomcat.util.threads.taskthread$wrappingrunnable.run (taskthread.java:61)
At Java.lang.Thread.run (thread.java:745)

The data was checked because Tomcat added validation for HTTP headers after version 7.0.73, 8.0.39, 8.5.7.

The RFC3986 documentation stipulates that only English letters (A-ZA-Z), Numbers (0-9),-_.~4 special characters, and all reserved characters are allowed in the URL.

The following characters are reserved characters in RFC3986:

!* ' ();: @&=+$,/?#[]

Unsafe characters

There are also some characters that may cause ambiguity in the parser when they are placed directly in the URL. These characters are considered unsafe characters for a number of reasons.

Space URL in the process of transmission, or the user in the process of typesetting, or text handlers in the process of processing URLs, it is possible to introduce insignificant spaces, or the meaningful spaces to remove

quotation marks and <> and angle brackets are often used to delimit URLs in plain text

#Usually used to represent bookmarks or anchors

The->% percent semicolon itself is used as a special character to encode unsafe characters, so it needs to be encoded

->{}|\^[] ' ~ Some gateways or transport agents will tamper with these characters

Specifically:

Org.apache.tomcat.util.http.parser.httpparser#is_not_request_target[] Defines a heap of not REQUEST TARGET

if (Is_control[i] | | i > 127 | | i = = | | | i = = | | i = = | | i = = | | i = = | | | i = = | | | i = = 94 | | i = = 96 | | i = = 123 | | i = = 124 | | i = =) {

               Is_not_request_target[i] = true;

           }

The conversion is the following characters (corresponding to 10 ASCII): Those controls on the keyboard: (<32 or =127) non-English characters (>127) spaces (32) double quotation marks (three) < (62) backslash (92) ^ (94) tab above the key, I do not know the young read (96) {(123)} (124) | (125)

After consulting a large amount of information, there are three solutions:

Plan 1:
Replace the lower version of Tomcat to circumvent this problem.

I then downloaded a 7.0.41 tomcat, configured to idea or eclipse, and it was ready.

Plan 2:
Add the last line in Conf/catalina.properties:

Org.apache.tomcat.util.buf.udecoder.allow_encoded_slash=true

Add or modify:

tomcat.util.http.parser.httpparser.requesttargetallow=| {}

After restarting the server, resolve the issue.

Plan 3:

But eventually the want to encode your the URL on client:

encodeURI ("http://localhost:8080/app/handleResponse?msg=name|id|")
> Http://localhost:8080/app/handleResponse?msg=name%7Cid%7C

Or just query string:

encodeURIComponent ("msg=name|id|")
> msg%3dname%7cid%7c

Official Guide Address: http://tomcat.apache.org/tomcat-8.5-doc/config/systemprops.html

Official Note:

Org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH

If the is true '%2f ' and '%5c ' would be permitted as path.delimiters.If not specified, the default value of false would be Used.