性能测试问题解决——消息头缺失引起的400错误

篇一 : nginx 解决400 bad request 的方法（转载）

nginx的400错误比较难查找原因，因为此错误并不是每次都会出现的，另外，出现错误的时候，通常在浏览器和日志里看不到任何有关提示。［www.t262.com]

经长时间观察和大量试验查明，此乃request header过大所引起，request过大，通常是由于cookie中写入了较大的值所引起。

所幸在nginx中是有办法解决这个问题：

在nginx.conf中，将client_header_buffer_size和large_client_header_buffers都调大，可缓解此问题。

其中主要配置是client_header_buffer_size这一项，默认是1k，所以header小于1k的话是不会出现问题的。

按我现在配置是：

client_header_buffer_size 16k;

large_client_header_buffers 4 64k;

这个配置可接收16k以下的header，在浏览器中cookie的字节数上限会非常大，所以实在是不好去使用那最大值。

最好的解决办法当然是不要往cookie里写入太多的东西，不过如果是一个很大的网站，那么在一个二级域名写入了顶级域名下的cookie似乎是不好控制的，这需要制定一个规范来控制顶级域名的cookie写入量才可以解决得了。

这个可能也是nginx的一个bug，因为buffer这个词义上说为缓冲，也就是说，如果没取完的话，是会循环取直至取完的，但是nginx并没有进行循环的动作直接返回了400错误。nginx的下一个版本可能会修正这个问题。

---

最近发现16k的buffer居然还是不够用，改成128k了，变态一点对nginx来说也不是很大问题，重要是人不能因为这种事情搞疯了

---

有朋友发现nginx在后台接收到很大的header时也会出现400错误，如：

2008/08/02 22:51:14 [error] 16613#0: *105 upstream sent too big header while reading response header from upstream, client: 。。。。。。。。。。。。。

在nginx的wiki里找了一遍，没有找到合适的语句，wiki更新过慢？于是查了一遍源码，在ngx_http_proxy_module.c也没有找到合适的语句。

不过在nginx 0.3.12版的更新里有这么一句话：

*) Change: the "proxy_header_buffer_size" and

  "fastcgi_header_buffer_size" directives was renamed to the

  "proxy_buffer_size" and "fastcgi_buffer_size" directives.

不清楚作者改名用意何在，不过，proxy_buffer_size之前的名字proxy_header_buffer_size倒是有点合适，如果有朋友老遇到后台接收时抛出400错误，可以增大这个参数一试。

原文地址：http://bbs.phpchina.com/forum.php?mod=viewthread&tid=207086

篇二 : Bad Request (Invalid Hostname)

Bad Request (Invalid Hostname)：错误请求（无效主机名）

一、域名未绑定或网站已经停止

二、域名已绑定主机，但主机未绑定域名就会出现这种情况！

三、总结页面出现BadRequest(InvalidHostname)的原因：

1、如果确定域名已经解析生效，但是仍然不能访问，出现BadRequest(InvalidHostname)。［www.t262.com）那么这就可能是您没有绑定该域名的原因

2、也有一部分情况，比如一部分程序你上传之后就是用服务商提供的三级域名访问也是那个样子。也会有BadRequest(InvalidHostname)的错误提示

3、也许是限制了访问线程。也就是说当同时访问该网页超过一定人数的时候，其它人浏览时就会出现你所说的情况

扩展：invalid hostname / hostname is invalid / iis invalid hostname

篇三 : Error -26631: HTTP Status-Code=400 (Bad Request) for

最近在做性能测试，在开发web脚本的过程中遇到错误：Action.c(15): Error -26631: HTTP Status-Code=400 (Bad Request) forhttp://xxxxxx/onlinefront/s.do?tl=51&bk=null&optionId=244&p=110

问了很多人没有人知道问题的原因，最后只能自己潜心研究，首先从http status-code400的错误开始分析,这个错误是说请求无法被处理，因为它含有缺失或无效的信息,根据错误信息的描述应该是发送HTTP请求中语法格式不正确导致不被服务器接受，这很可能就是通过LoadRunner发送HTTP请求是一个不完整。[www.t262.com)那么首先要确认的就是比较发出的请求和录制的时候请求看是否丢失了http信息来判断错误的原因。

首先选上runtimesettings中extended log的三个选项后运行此脚本，用录制发送相类似请求的日志和选择exection log的http send请求日志进行对比。拷贝这些请求数据包到一个记事本中然后进行比较。在Recording Log（单协议）或Generation Log（多协议）中查找是否存在头数据包，我们发现在执行日志中头域失踪了。

这样解决问题的方法就是用web_add_header("xxxxx","yyyy")添加一个http头，在错误的请求前添加此函数然后回放。

如果你发现所有的HTTP send请求都缺少头数据包，在脚本中的开头添加web_add_auto_header（”XXXXX“，”yyyy“）;随着web_add_auto_header的添加，你不需要为每个HTTP send请求都添加web_add_header了。

还有一个解决问题的方法是在Tools -> Recording Options -> Advanced tab中设置，点“headers”按钮，在列表中选择“Record Headers in the List”，然后选择“XXXXX”，因此它可确保在录制过程中录制自己。

扩展：bad request code / code 400 bad request / request.status

欢迎转载：http://www.t262.com/read/154731.html