我们在jboss上托管了一个servlet，它可以处理HttpServletRequest。但是有时候我们收到的请求没有被jboss解码，当我们在HttpServletRequest上执行getQueryParam时，我们得到的是null。jboss访问日志以编码的形式显示url。通常情况下，当一切顺利时，url在访问日志中显示为解码的。例如：
这是一个有问题的要求：
127.0.0.1 [13/Apr/2009:14:18:53 +0000] GET /redirectService//%3Fclient_id=3&redirect_url=http%253A%252F%252Fwww.amazon.de%252Fgp%252Fsearch%253Fie%253DUTF8%2526keywords%253DMicrosoft+Office+2007%2526search-alias%253Dsoftware%2526 HTTP/1.1 'null' 'Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12)'这是一个正当的要求：
127.0.0.1 [13/Apr/2009:14:19:37 +0000] GET /redirectService//?client_id=3&redirect_url=http%3A%2F%2Fwww.amazon.de%2Fgp%2Fsearch%3Fie%3DUTF8%26keywords%3DMAGIX+Video+deluxe+2008%26search-alias%3Dsoftware%26 HTTP/1.1 'http://www.google.de/search?hl=de&q=magix+video+deluxe+2008&meta=&aq=3&oq=%22magix%22' 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322)'我们是否缺少一些jboss解码设置，或者这只是恶意用户的情况？
3条答案
按热度按时间8wtpewkr1#
很难说，真的。
客户端似乎将问号解码为“%3F”，而不是&。很可疑，不是吗？。这看起来像是一个有缺陷的客户端IMO。可能是不可移植的javascript，可能是Web服务器端的一些URL重写错误，或者更深奥的原因...一个有故障的浏览器插件。
要排除不可移植的javascript，请记录用户代理并比较结果。要排除url重写错误，请记录引用。
AFAIK，URL解码器的行为是硬编码的。字符串编码可以改变，如果URI的被写在非ascii或非iso88591，但这不是你所追求的。什么编码问号，但不能编码与符号我搞不懂。
l0oc07j22#
我们记录了用户代理，它是一些可疑的“XXXagentXXX”在大多数情况下，但一个真正的Mozilla（如上所述）在其他人。Referrer是“-”为所有这些请求。然而，有一个奇怪的事情，我今天注意到。我们重定向我们的请求从apache（80）到jboss。Apache访问日志显示上述请求完全编码：
而jboss访问日志中除了%3F之外的所有内容都被解码了。现在这让我觉得apache在解码的某个地方搞砸了？
wnavrhmk3#
我在使用JBoss 13解码URL时也遇到了问题。
我在JBoss配置中添加了最后一行，它现在可以工作了。
如果需要更多信息，请联系医生：https://wildscribe.github.io/WildFly/13.0/subsystem/undertow/server/http-listener/index.html