1. 信息收集与初步分析

1.1 报错信息

[error] [client 192.168.1.1] Invalid Content-Length, referer: https://192.168.1.7/datamanage/personaldatamanage.html
[error](-3)Unknown error 4294967293: proxy: prefetch request body failed to 192.168.192.1 from 192.168.1.1 ()

ap_run_create_request
|__ap_proxy_http_request
   |__ap_get_brigade



1. setup_client_block()在请求处理的开始，设置所有必须的属性
2. should_client_block()告诉模块是否读取输入
3. get_client_block
ap_setup_client_block
|__const char *lenp = apr_table_get(r->headers_in, "Content-Length");
   if (lenp) {
       conversion_error = 1;
   }
   return HTTP_BAD_REQUEST;



process_mkcol_body
|__const char *lenp = apr_table_get(r->headers_in, "Content-Length");
   if (lenp) {
       const char *pos = lenp;

        while (apr_isdigit(*pos) || apr_isspace(*pos)) {
            ++pos;
        }

        if (*pos != '\0') {
            /* This supplies additional information for the default message. */
            ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
                          "Invalid Content-Length %s", lenp);
            return HTTP_BAD_REQUEST;
        }
    }



/*只有在成功解析出headers之后才会使用*/
ap_http_filter
|__lenp = apr_table_get(f->r->headers_in, "Content-Length");
   errno = 0;
   ctx->remaining = strtol(lenp, &endstr, 10);  /* we depend on ANSI */
   if (errno || (endstr && *endstr) || (ctx->remaining < 0)) {
       conversion_error = 1;
   }
   return ap_pass_brigade(f->r->output_filters, bb);

request_rec {
    /** MIME header environment from the request */
    apr_table_t *headers_in;
}

1. setup_client_block()在请求处理的开始，设置所有必须的属性
2. should_client_block()告诉模块是否读取输入
3. get_client_block

1.2 分析

通过对报错信息Invalid Content-Length的查找，找到了以下三个接口函数：

ap_setup_client_block
process_mkcol_body
ap_http_filter

通过gdb调试，暂定为ap_http_filter报出的错误信息。
查看ap_http_filter函数：

//获取Content-Length值
lenp = apr_table_get(f->r->headers_in, "Content-Length");
//将字符串转换为long int类型
ctx->remaining = strtol(lenp, &endstr, 10); /* we depend on ANSI */
if (errno || (endstr && *endstr) || (ctx->remaining < 0)) {
    conversion_error = 1;
}
if (conversion_error) {
    ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, f->r, "Invalid Content-Length");
}

ctx->remaining的类型：

apr_off_t<-off_t<-long int

off_t类型用于指示文件的偏移量，常就是long类型，其默认为一个32位的整数，在gcc编译中会被编译为long int类型，在64位的Linux系统中则会被编译为long long int，其定义在unistd.h头文件中可以查看。
long int值的范围–2,147,483,648到2,147,483,647。
当接受一个2GB（2,147,483,648 ）的值时将导致ctx->remaining溢出为负数。数据类型范围参考

2. 近一步分析

2.1 hrp如何存储http body

2.2 httpd 2.4是否存在long类型溢出问题

当查看httpd 2.4是如何处理溢出问题的时候，发现其使用apr_strtoff接口，并注释防止上溢或者下溢。
我想到httpd 2.2会不会也对防止溢出做了处理，需要回头检查以下。
httpd2.2使用strtol接口，在重新查看说明的时候发现了这句话：

如果转换得到的值超出 long int 所能表示的范围，函数将返回 LONG_MAX 或 LONG_MIN（在 limits.h 头文件中定义），并将 errno 的值设置为 ERANGE。

我使用了如下程序模仿2GB的流程：

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <errno.h>

int main()
{
  char *lenp1 = "2147483647";
  char *lenp2 = "2147483648";
  char *lenp3 = "2147483649";
  char *endstr;
  errno = 0;
  long int remaining1, remaining2, remaining3;
  remaining1 = strtol(lenp1, &endstr, 10);
  printf("errno:%d", errno);
  remaining2 = strtol(lenp2, &endstr, 10);
  printf("errno:%d", errno);
  remaining3 = strtol(lenp3, &endstr, 10);
  printf("errno:%d", errno);
  printf("remaining1:%ld\n", remaining1);
  printf("remaining2:%ld\n", remaining2);
  printf("remaining3:%ld\n", remaining3);
  return 0;
 }

执行结果：

SSL5-DEV-01:~/test/2# ./a.out
errno:0errno:34errno:34remaining1:2147483647
remaining2:2147483647
remaining3:2147483647

当发生溢出的时候返回错误码34。并取其最大值2147483647

接下来测试httpd 2.4的处理流程

附：LimitRequestBody Directive解析

描述：限制从客户端发送的HTTP请求正文的总大小
语法：LimitRequestBody bytes
默认：LimitRequestBody 0

此指令指定请求正文的字节数，从0（表示无限制）到2147483647（2GB）

LimitRequestBody指令允许用户在给定指令的上下文（服务器，每个目录，每个文件或每个位置）内设置HTTP请求消息体的允许大小限制。 如果客户端请求超出该限制，服务器将返回错误响应，拒绝为请求提供服务。 正常请求消息体的大小将根据资源的性质和该资源上允许的方法而有很大差异。 CGI脚本通常使用消息正文来检索表单信息。 PUT方法的实现将需要至少与服务器希望为该资源接受的任何表示一样大的值。