Le 26/11/2016 à 16:10, Willy Tarreau a écrit :
Hello,
On Sat, Nov 26, 2016 at 04:19:08PM +0800, Live Dev wrote:
Hello,
this is actually my first time posting to the mailing list
Welcome then :-)
really excited to hear about the 1.7 release and thrilled to try out the
new features like SPOE and OpenSSL 1.1.0 support
kudos to willy and all others who made this happen!
however in my use case (which utilizes CONNECT requests, alongside GET and
POST) some initial testing shortly following an upgrade to 1.7 seems to
suggest i'm hitting a bug at the CONNECT requests
Hmmm you're perfectly right, I've just reproduced it. I could bisect it,
it was brought by the patch below. I'm very surprized that none of us had
detected it yet, as this bug has been present for a while now. It probably
means that few people experiment with development code in front of proxies
(which probably makes sense) :
commit d7c9196ae56e8ee6babca07ec2ec98a4146bcfd1
Author: Christopher Faulet <cfau...@qualys.com>
AuthorDate: Thu Apr 30 11:48:27 2015 +0200
Commit: Willy Tarreau <w...@1wt.eu>
CommitDate: Tue Feb 9 14:53:15 2016 +0100
MAJOR: filters: Add filters support
This patch adds the support of filters in HAProxy. The main idea is to have
a
way to "easely" extend HAProxy by adding some "modules", called filters,
that
will be able to change HAProxy behavior in a programmatic way.
It will not be the funniest one to debug (at least for me), but it's very
easy to reproduce. I guess it's related to the changes on the forwarding
path to insert the data hooks. I'll check this on Monday with Chris who
knows this part very well. We'll also have to check that Upgrade still
works correctly.
Hi,
Here is the patch. It fixed the CONNECT requests. The bug affects only
these requests. The HTTP connection upgrade is not concerned here (I've
checked it with the WebSockets).
--
Christopher
>From 38da774c8158a3793a5261b816454206bd1f0ef1 Mon Sep 17 00:00:00 2001
From: Christopher Faulet <cfau...@haproxy.com>
Date: Mon, 28 Nov 2016 10:14:03 +0100
Subject: [PATCH] BUG/MEDIUM: http: Fix tunnel mode when the CONNECT method is
used
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4
When a 2xx response to a CONNECT request is returned, the connection must be
switched in tunnel mode immediatly after the headers, and Transfer-Encoding and
Content-Length headers must be ignored. So from the HTTP parser point of view,
there is no body.
The bug comes from the fact the flag HTTP_MSGF_XFER_LEN was not set on the
response (This flag means that the body size can be determined. In our case, it
can, it is 0). So, during data forwarding, the connection was never switched in
tunnel mode and we were blocked in a state where we were waiting that the
server closes the connection to ends the response.
Setting the flag HTTP_MSGF_XFER_LEN on the response fixed the bug.
---
src/proto_http.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/proto_http.c b/src/proto_http.c
index 04aaf90..c24c01e 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -6320,7 +6320,8 @@ int http_wait_for_response(struct stream *s, struct channel *rep, int an_bit)
*/
if (txn->meth == HTTP_METH_HEAD ||
(txn->status >= 100 && txn->status < 200) ||
- txn->status == 204 || txn->status == 304) {
+ txn->status == 204 || txn->status == 304 ||
+ (txn->meth == HTTP_METH_CONNECT && txn->status == 200)) {
msg->flags |= HTTP_MSGF_XFER_LEN;
goto skip_content_length;
}
--
2.7.4
