Le 26/02/2019 à 21:29, PiBa-NL a écrit :
Hi List, Christopher,
With 2.0-dev1-6c1b667 and 2.0-dev1-12a7184 i get the 'failure' below
when running reg-tests with HTX enabled. (without HTX the test passes)
Seems this commit made it return different results:
http://git.haproxy.org/?p=haproxy.git;a=commit;h=b8d2ee0406666aa21f2906a4921e5e1c7afefb7e
I 'think' the syslog output for a single request/response should remain
the same with/without htx? Or should the size check be less strict or
accept 1 of 2 possible outcomes with/without htx.?
Regards,
PiBa-NL (Pieter)
**** S 0.0 syslog|<134>Feb 26 20:42:52 haproxy[56313]: ::1:46091
[26/Feb/2019:20:42:52.065] fe be/srv 0/0/0/2/2 200 17473 - - ----
1/1/0/0/0 0/0 {HPhx8n59qjjNBLjP} {htb56qDdCcbRVTfS} "GET / HTTP/1.1"
** S 0.0 === expect ~ "[^:\\[ ]\\[${h_pid}\\]: .* .* fe be/srv .*
200 176...
---- S 0.0 EXPECT FAILED ~ "[^:\[ ]\[56313\]: .* .* fe be/srv .* 200
17641 - - ---- .* .* {HPhx8n59qjjNBLjP} {htb56qDdCcbRVTfS} "GET /
HTTP/1\.1""
Hi Pieter,
Well, it's expected. The size reported in the logs is the size of data
written in the response channel. With the legacy HTTP, the parsing is
done by the HTTP analyzers. Received data are directly written into the
channel's buffer. So the size reported is the response size as received
from the server. In HTX, the parsing is done by the H1 multiplexer and
HTX data are then copied into the channel's buffer. So the size reported
differs because of the HTX overhead. Note that chunked encoded messages
are unchunked during the parsing, so the size reported may be lower in
HTX, depending how data are chunked.
So, that's probably a temporary drawback. We need to get more
information from the multiplexers (h1 or h2) to have more accurate logs.
Some things that should be move in the mux are still done at the channel
level for now. Not only about logs. However, while the legacy HTTP is
still there, it is a bit hard to start this refactoring.
BTW, I missed to update the reg-test. I will do so.
Thanks,
--
Christopher Faulet
