所以我在Jetty servlet面前使用HAProxy.
目前的目标只是在配置完所有内容后进行概念验证,加载和压力测试.
但是我在配置haproxy时遇到问题.我知道这不是我的应用程序的问题,因为我有运行nginx(tengine),一切正常.所以它必须与haproxy配置或haproxy工作的方式不适合我的需要.

所以我的客户端尝试做的是使用两个不同的连接连接到haproxy并保持它们打开.
1.连接分块流模式以进行上传.
2.连接正常模式并建立下载通道.

这是我的haproxy.conf文件的样子：

global
log /dev/log    local0
log /dev/log    local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon

# Default SSL material locations
# ca-base /etc/ssl/certs
# crt-base /etc/ssl/private

# Default ciphers to use on SSL-enabled listening sockets.
# For more information, see ciphers(1SSL).
ssl-default-bind-ciphers kEECDH+aRSA+AES:kRSA+AES:+AES256:RC4-SHA:!kEDH:!LOW:!EXP:!MD5:!aNULL:!eNULL
maxconn 2048

defaults
log global
mode    http
option forwardfor
option http-server-close
option  httplog
option  dontlognull
timeout connect 5000
timeout client  50000
timeout server  50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
stats enable
stats uri /stats
stats realm Haproxy\ Statistics
stats auth user:password

frontend www-http
   bind *:80
   reqadd X-Forwarded-Proto:\ http
   default_backend www-backend

frontend www-https
   bind *:443 ssl crt /etc/haproxy/server.pem
   reqadd X-Forwarded-Proto:\ https
   default_backend www-backend

backend www-backend
    redirect scheme https if !{ ssl_fc }
    server www-1 localhost:8080 check maxconn 2048

这是我尝试访问端口443时我的日志所说的内容：

Sep 17 11:10:18 xxxxx-pc haproxy[15993]: 127.0.0.1:32875 [17/Sep/2014:11:10:18.464] www- https~ www-backend/www-1 0/0/0/-1/1 502 212 – – PH– 0/0/0/0/0 0/0 “GET /test HTTP/1.1”

任何想法可能是什么问题？
配置问题还是？

谢谢.

解决方法:

PH意味着haproxy拒绝了后端的头部,因为它格式不正确.
http://www.haproxy.org/download/1.4/doc/configuration.txt

PH – The proxy blocked the server’s response, because it was invalid,
incomplete, dangerous (cache control), or matched a security filter.
In any case, an HTTP 502 error is sent to the client. One possible
cause for this error is an invalid syntax in an HTTP header name
containing unauthorized characters. It is also possible but quite
rare, that the proxy blocked a chunked-encoding request from the
client due to an invalid syntax, before the server responded. In this
case, an HTTP 400 error is sent to the client and reported in the
logs.