The valid characters are defined in RFC 7230 and RFC 3986异常

发表于

The valid characters are defined in RFC 7230 and RFC 3986异常

使用springboot-1.5.2版本服务器tomcat,遇到这个问题我最先百度了下RFC 7230 and RFC 3986的大致内容。有一篇文章叫(http://blog.csdn.net/qq_32010299/article/details/51790407)其中描述到
“RFC3986文档规定，Url中只允许包含英文字母（a-zA-Z）、数字（0-9）、-_.~4个特殊字符以及所有保留字符。”,
完整的异常栈信息

1
2
3
4
5
6
7
8
9
10
11
12
ote: 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:471) ~[tomcat-embed-core-8.5.11.jar:8.5.11]
	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:667) ~[tomcat-embed-core-8.5.11.jar:8.5.11]
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) [tomcat-embed-core-8.5.11.jar:8.5.11]
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:798) [tomcat-embed-core-8.5.11.jar:8.5.11]
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1434) [tomcat-embed-core-8.5.11.jar:8.5.11]
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-8.5.11.jar:8.5.11]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_101]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_101]
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-8.5.11.jar:8.5.11]
	at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]

跟进去会发现命中的了org.apache.tomcat.util.http.parser.HttpParser中的IS_NOT_REQUEST_TARGET规则.这个类的部分信息如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
/**
 * HTTP header value parser implementation. Parsing HTTP headers as per RFC2616
 * is not always as simple as it first appears. For headers that only use tokens
 * the simple approach will normally be sufficient. However, for the other
 * headers, while simple code meets 99.9% of cases, there are often some edge
 * cases that make things far more complicated.
 *
 * The purpose of this parser is to let the parser worry about the edge cases.
 * It provides tolerant (where safe to do so) parsing of HTTP header values
 * assuming that wrapped header lines have already been unwrapped. (The Tomcat
 * header processing code does the unwrapping.)
 *
 */
public class HttpParser {
    private static final int ARRAY_SIZE = 128;
    private static final boolean[] IS_CONTROL = new boolean[ARRAY_SIZE];
    private static final boolean[] IS_SEPARATOR = new boolean[ARRAY_SIZE];
    private static final boolean[] IS_TOKEN = new boolean[ARRAY_SIZE];
    private static final boolean[] IS_HEX = new boolean[ARRAY_SIZE];
    private static final boolean[] IS_NOT_REQUEST_TARGET = new boolean[ARRAY_SIZE];
    private static final boolean[] IS_HTTP_PROTOCOL = new boolean[ARRAY_SIZE];
    // Not valid for request target.
    // Combination of multiple rules from RFC7230 and RFC 3986. Must be
    // ASCII, no controls plus a few additional characters excluded
    if (IS_CONTROL[i] || i > 127 ||
            i == ' ' || i == '\"' || i == '#' || i == '<' || i == '>' || i == '\\' ||
            i == '^' || i == '`'  || i == '{' || i == '|' || i == '}') {
        IS_NOT_REQUEST_TARGET[i] = true;
    }

结合上面的规则描述可以确定是tomcat做了RFC7230 and RFC 3986安全过滤,排查自己的请求参数发现里面包含了”filterParam={MALL:10073}”非法信息。
到此这个问题排查清楚了,可选方案:

1. 调整tomcat版本(8.0.38–> tomcat 8.5.11这个范围是有这个问题的,其他的版本没有测试不确定没有)
2. 更换服务器,我选择这个方案把服务器更新成了jetty.

以上.