apache - GWT-RPC、Apache、Tomcat 服务器数据大小检查

Question

跟进 this GWT-RPC question (and answer #1) re. field size checking ，我想知道检查反序列化前发送到服务器的最大数据大小的正确方法，比如if request data size > X then abort the request。重视简单性和基于对上述问题/答案的回答，我倾向于认为检查最大总体请求大小就足够了，更细粒度的检查(即字段级检查)可以推迟到反序列化后，但我对任何最佳实践建议。

感兴趣的技术堆栈:GWT-RPC 客户端-服务器与 Apache-Tomcat 前端网络服务器的通信。

我想第一步是全局限制任何请求的大小(LimitRequestBody 在 httpd.conf 或/和其他？)。
是否有更细粒度的检查，比如可以根据 RPC 请求设置的检查？如果是这样，在哪里，如何？更细粒度的检查能为一个全局设置带来多少安全值(value)？

为了通过示例更具体地构建问题，假设我们在同一个 servlet 上有以下两个 RPC 请求签名:

public void rpc1(A a, B b) throws MyException;
public void rpc2(C c, D d) throws MyException;

假设我大致知道以下最大尺寸:

• 一个:10kB
• b: 40kB
• c: 1 M B
• d: 1kB

然后我期望以下最大尺寸:

• rpc1:50kB
• rpc2:1MB

在这个例子的上下文中，我的问题是:

1. 在何处/如何配置任何请求的最大大小——即我上面示例中的 1 MB？我相信它是 httpd.conf 中的 LimitRequestBody 但不能 100% 确定它是否是用于此目的的唯一参数。
2. 如果可能，在何处/如何配置每个 servlet 的最大大小——即我的 servlet 中任何 rpc 的最大大小为 1 MB？
3. 如果可能，在哪里/如何配置/检查每个 rpc 请求的最大大小——即，最大 rpc1 大小为 50 kB，最大 rpc2 大小为 1 MB？
4. 如果可能，在哪里/如何配置/检查每个 rpc 请求参数的最大大小——即，a 是 10 kB，b 是 40 kB， c 为 1 MB，d 为 1 kB。我怀疑进行后反序列化具有实际意义，不是吗？
5. 出于基于成本/ yield 的实际目的，通常建议使用什么级别的反序列化前检查——1. 全局，2. servlet，3. rpc，4. 对象参数？换句话说，上述每个预反序列化级别检查的一方面的成本复杂性和另一方面的附加值大致是多少？

提前致谢。

Answer 1

根据我提出问题后所学到的知识，在有人能更好地向我展示之前，我自己的答案和策略是:

1. 第一道防线和检查是在 httpd.conf 中设置的 Apache 的 LimitRequestBody。它是所有 servlet 中所有 rpc 调用的总最大值。
2. 第二道防线是通过覆盖 GWT AbstractRemoteServiceServlet.readContent 进行 servlet 预反序列化。例如，我想可以按照下面进一步显示的方式进行操作。这是我在这个问题中寻找的核心。
3. 然后可以进一步检查反序列化后的每个 rpc 调用参数。可以在服务器端和客户端方便地使用 JSR 303 验证——参见引用资料 StackOverflow和 gwt关于。客户端。

关于如何覆盖 AbstractRemoteServiceServlet.readContent 的示例:

@Override 
protected String readContent(HttpServletRequest request) throws ServletException, IOException
{
  final int contentLength = request.getContentLength();
  // _maxRequestSize should be large enough to be applicable to all rpc calls within this servlet.
  if (contentLength > _maxRequestSize)
    throw new IOException("Request too large");
  final String requestPayload = super.readContent(request);
  return requestPayload;
}

参见 this question如果最大请求大小 > 2GB。

从安全的角度来看，这种策略对我来说似乎很合理，可以控制用户发送到服务器的数据大小。