Hi Cyril,
OK, now I understand better your logics on this one. Initially I didn't
understand because I did not read the patch in its whole context, but
given the remaining checks on the PR_O2_FAKE_KA later, I agree that your
solution looks like the best one. I have tried it and I can confirm it
does what we want in every situation I could make up (with both HTTP/1.0
and HTTP/1.1).
However, I was worried about the impact once we have server-side keep-alive.
So I tried to change it slightly so that it sets TX_CON_WANT_KAL instead of
TX_CON_WANT_SCL, since after all it matches what we're looking for : announce
keep-alive to the server. And doing so gave me the exact same results. Here's
a copy-paste of the first chunk of the patch :
@@ -3062,7 +3062,8 @@ int http_process_req_common(struct session *s, struct
buffer *req, int an_bit, s
(s->be->options &
(PR_O_KEEPALIVE|PR_O_SERVER_CLO|PR_O_HTTP_CLOSE|PR_O_FORCE_CLO)))) {
int tmp = TX_CON_WANT_TUN;
- if ((s->fe->options|s->be->options) & PR_O_KEEPALIVE)
+ if ((s->fe->options|s->be->options) & PR_O_KEEPALIVE ||
+ ((s->fe->options2|s->be->options2) & PR_O2_FAKE_KA))
tmp = TX_CON_WANT_KAL;
if ((s->fe->options|s->be->options) & PR_O_SERVER_CLO)
tmp = TX_CON_WANT_SCL;
I also find it easier to understand that it will announce keep-alive to the
server if we set WANT_KAL than if we set WANT_SCL. To me, it means "announce
keep-alive to the server, whatever you'll use with the client".
If you agree with this change, I'll apply it that way. I'll also remove the
leftover from a previous fix consisting in a "&& 1" to replace a condition
checking FAKE_KA.
I think that a 1.4.12 will be needed, considering we already had a report for
this issue :-/
Thanks !
Willy
