1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
# commit 70d318c
# BUG/MEDIUM: lua: possible CLOSE-WAIT state with '\n' headers
#
# The Lua parser doesn't takes in account end-of-headers containing
# only '\n'. It expects always '\r\n'. If a '\n' is processes the Lua
# parser considers it miss 1 byte, and wait indefinitely for new data.
#
# When the client reaches their timeout, it closes the connection.
# This close is not detected and the connection keep in CLOSE-WAIT
# state.
#
# I guess that this patch fix only a visible part of the problem.
# If the Lua HTTP parser wait for data, the timeout server or the
# connectio closed by the client may stop the applet.
varnishtest "possible CLOSE-WAIT with '\n' headers"
#REQUIRE_OPTIONS=LUA
#REGTEST_TYPE=bug
feature ignore_unknown_macro
syslog Slog -level info -repeat 100 {
recv info
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Ta=[0-9]* Tc=[0-9]* Td=[0-9]* Th=[0-9]* Ti=[0-9]* Tq=[0-9]* TR=[0-9]* Tr=[0-9]* Tt=[0-9]* Tw=[0-9]*"
} -start
haproxy h1 -conf {
defaults
timeout client "${HAPROXY_TEST_TIMEOUT-5s}"
timeout connect "${HAPROXY_TEST_TIMEOUT-5s}"
global
tune.lua.bool-sample-conversion normal
lua-load ${testdir}/close_wait_lf.lua
frontend frt
log ${Slog_addr}:${Slog_port} local0 debug err
log-format Ta=%Ta\ Tc=%Tc\ Td=%Td\ Th=%Th\ Ti=%Ti\ Tq=%Tq\ TR=%TR\ Tr=%Tr\ Tt=%Tt\ Tw=%Tw
mode http
bind "fd@${frt}"
http-request use-service lua.donothing
} -start
client c1 -connect ${h1_frt_sock} -repeat 100 {
send "GET / HTTP/1.1\n\n"
} -run
syslog Slog -wait
shell {
set +e
ss -pt | grep CLOSE-WAIT.*haproxy.*pid=${h1_pid}
exit $((!$?))
}
|
