apache - 分派(dispatch)传入的RPC调用时发生异常:encodeRequest不能为空

Question

这里描述了类似的问题：GWT IllegalArgumentException: encodedRequest cannot be empty

我的GWT应用程序部署在Tomcat6中，该Tomcat6通过Coyote / JK2连接器与Apache链接。对于SSO，我使用mod_auth_sspi / 1.0.4。

当我使用IE8时，不显示页面，但是对于Firefox来说一切正常。在Tomcat日志中，我看到以下内容：

SEVERE: Exception while dispatching incoming RPC call
java.lang.IllegalArgumentException: encodedRequest cannot be empty
    at com.google.gwt.user.server.rpc.RPC.decodeRequest(RPC.java:232)
    at org.spring4gwt.server.SpringGwtRemoteServiceServlet.processCall(SpringGwtRemoteServiceServlet.java:32)
    at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)
    at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:643)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:723)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at gov.department.it.server.RequestInterceptorFilter.doFilter(RequestInterceptorFilter.java:90)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
    at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
    at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:311)
    at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:776)
    at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705)
    at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898)
    at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
    at java.lang.Thread.run(Thread.java:619)

到目前为止，我尝试了什么：

1）找不到注册表项 DisableNTLMPreAuth（恕我直言，这不是解决方案，因为在我的情况下，正在积极使用IE 8）。

2）我已经安装并配置了本地Windows身份验证框架 WAFFLE

web.xml：

...
<filter>
    <filter-name>NegotiateSecurityFilter</filter-name>
    <filter-class>waffle.servlet.NegotiateSecurityFilter</filter-class>
    <init-param>
        <param-name>waffle.servlet.spi.NegotiateSecurityFilterProvider/protocols</param-name>
        <param-value>NTLM</param-value>
    </init-param>
</filter>
...
<filter-mapping>
    <filter-name>NegotiateSecurityFilter</filter-name>
    <url-pattern>/my-app/*</url-pattern>
</filter-mapping>
...

但这没有帮助。

3）在 worker.properties中，我设置了 socket_keepalive=0，但它也没有帮助-

worker.ajp13.type=ajp13
worker.ajp13.host=localhost
worker.ajp13.port=8009
worker.ajp13.lbfactor=50
worker.ajp13.cachesize=10
worker.ajp13.cache_timeout=600
worker.ajp13.socket_keepalive=0
worker.ajp13.socket_timeout=300

我还能尝试做什么？

Answer 1

您已经在mod_auth_sspi中重新发现了7岁的bug #1，它影响了许多项目，使许多开发人员感到沮丧，并且多年来造成了不可数的浪费工时。但是由于维护者doesn't consider it a bug，它仍然无法解决。 Microsoft也没有针对较旧的浏览器解决此问题，因为有迹象表明IE9没有此问题。

原因

这是由于IE尝试变得“智能”并发送零内容长度的POST（我将其命名为0POST尝试使其成为可索引的字词，以使在未来7年内重新发现它的用户受益）。标头预期会受到服务器的挑战。 IE在该保护空间中经过身份验证后会执行此操作。因此，它知道它将再次受到挑战。遗憾的是，mod_auth_sspi不如IE聪明，因此，当0POST到达时，服务器端会发生不好的事情，并且它会直接传递给应用程序而不会受到挑战。除了有时即使对于未保护的区域也可能发生这种情况，即使它们位于需要验证的区域之下。
其他浏览器并不假装像IE一样聪明，也不会在第一次往返过程中尝试为“性能”节省一些字节，因此不会遇到这个问题。这是此行为的Microsoft's explanation。

可怕的解决方法

在Apache httpd.conf中设置

SSPIPerRequestAuth On

这等效于您提到的 DisableNTLMPreAuth IE客户端修复程序，这对于大型用户组是不切实际的。加上它也使所有非Apache应用程序瘫痪，这些应用程序可能能够处理0POST。实际上，在网络上没有讨论这种设置的任何示例，也没有在网络上解释其副作用，因此我加入了这个 only link，我发现它对此有所启发。无论如何，进行一次服务器端更改似乎是两个弊端中较小的一个。尽管现在通过更改服务器配置，您也使访问此站点的所有其他无辜浏览器也受到了损害。

此解决方法的问题在于，它会强制每个请求都执行SSPI握手，这会导致大量额外的401流量，并可能影响性能。为了提高性能，NTLM身份验证被视为“基于会话”而不是“基于请求”，这意味着握手仅在会话开始时发生。使用此设置时，还应设置过滤器，以防止日志填充401s。另请注意，这需要打开KeepAlive。

我不确定您的设置是否与WAFFLE修复程序中所述的设置相同；他们像您一样使用Apache吗？我认为WAFFLE适用于Tomcat，而您前面有Apache，因此Apache正在处理身份验证。您可能会考虑使用该设置而不是Apache。如果可以使用该设置，则它可能是比该解决方法更好的选择，因为WAFFLE已明确考虑了0POST和 can handle it。像您一样与GWT合作时，作者拥有 also discovered this宝石。

有趣的是，对于jcifs， a fix for this very issue was posted是9年前。作者随后还提供了 excellent explanation：


  过滤器中的代码检查所有HTTP POST请求并确定
  如果它们包含NTLM类型1消息。如果请求中包含
  NTLM 1型消息，过滤器以虚拟2型消息响应
  满足IE在提交任何内容之前重新协商NTLM的愿望
  发布数据。然后，浏览器应使用NTLM类型3进行响应
  消息以及过滤器应允许的发布数据
  链接到Web应用程序的其余部分。


如果您有兴趣，还于5年前为mod_auth_sspi创建了 simple patch。作者自己的存储库中的 See diff。我不确定我是否同意这种方法。它尝试检测IE / 0POST，而我认为正确的解决方法应该是检测客户端是否正在请求具有NTLM Type 1标头的身份验证，如jcifs过滤器中所示。 （类型1仅表示它是握手的第一条消息）

我想知道是否有人使用了像 mod_auth_sspi这样的 mod_auth_ntlm_winbind替代方法，以及他们是否没有表现出这种行为。如果有，请发表评论。我们已经知道WAFFLE可以工作，但是它不是mod_auth_sspi的替代品。

一种选择是忘记NTLM并使用Kerberos（ mod_auth_kerb），但是许多人发现安装起来太复杂了。 IE在任何质询-响应方案中都将以这种方式表现，因此很可能遏制身份验证会遇到相同的问题，因为在两种情况下都会发生类似的401序列。但是作为一个不同的模块，它有可能能够处理此问题。

最后，我应该提到，还有另一个问题，这种按请求身份验证的解决方法似乎无法解决。我没有在任何地方讨论它，但是我发现有时在0POST之后，服务器会等待很长时间，然后服务器才返回带有（正确）POST结果的最后200个响应。但是，这种较长的延迟只会在最后发生，而不会立即响应0POST。这样就很好了，握手完成了，但是服务器直到很长一段时间后才响应，我注意到这很可疑地接近90秒，例如某种超时。实际的结果是，当用户登录时，IE8有时会挂起90秒以等待服务器响应。我以为 KeepAlive可能是导致它的原因，但是在我的配置中甚至没有明确定义它，因此我假设它是Apache 15秒默认设置。但是我确信这与0POST有关，因为它仅在成功进行0POST身份验证握手后立即发生。我们的服务器位于跨防火墙的单独（两向）受信任域中，因此可能与它有关。

本期的各种例子


https://confluence.atlassian.com/display/JIRAKB/NullPointerException+when+Authenticating+from+IE
http://trac.edgewall.org/ticket/2696
http://trac.edgewall.org/ticket/4560
https://drupal.org/node/82530
http://www.webmasterworld.com/apache/3087425.htm
Why "Content-Length: 0" in POST requests?
https://jira.springsource.org/browse/SEC-1087


最可笑的例子是IE的智能如何影响了微软自己的产品！他们自己不知道如何处理IE的行为，从而导致ISA Server 2006中的错误。


http://support.microsoft.com/kb/942638