Le 11/04/2018 à 16:11, Hessam Mirsadeghi a écrit :
Hi Christopher,

You're right; that segfault happens with the build at the faulty commit and not later versions such as v1.8.5. However, version v1.8.5 does segfault with the attached modified Lua script. As far as I can tell, the problem arises after any call to "txn.res:set()".

In the attached Lua script, if you remove the call to either of "txn.res:set(txn.res:get())" or "txn.res:forward(txn.res:get_in_len())", the segfault will disappear. Also, when I only have a call to "txn.res:set(txn.res:get())" in the script, haproxy becomes unresponsive to all but the first request on each persistent connection. That is, something like "curl -sig localhost:80 localhost:80" will only get the response for the first request; the second one times out on the existing connection and succeeds only on a a second connection established by curl.

So, with this script, I have a segfault. But not only with HAProxy 1.8 and higher. It also crashes on HAProxy 1.7. Actually, It will crash on all versions. This is a Lua problem not a HTTP one.

IMHO, "Channel.set" or "Channel.get" must never be used on HTTP messages. These functions totally hijack the HTTP parser. There is an attempt to restore the HTTP parser state. But this is only partially done (the headers' analysis is done, but not all of the ensuing analysis). So the result is undefined. It will seem to work for simpler cases but will fail most of time. Same remarks are true for "Channel.getline" and "Channel.append".

"Channel.forward" (and "Channel.send") must also never be used on HTTP messages. When called, the messages analysis is in progress. The HTTP parser expects to have all the headers at this stage. Mixing message analysis and data forward is totally unexpected.

I will let Thierry (the Lua maintainer) decide what to do. But, I guess he will restrict usage of all these functions to TCP streams only.

So now, maybe you can describe what you try to do. There is probably another way to achieve it. I hope so, because it will never work this way.

--
Christopher Faulet

Reply via email to