Thanks for your response Christopher.

What I want is to overwrite each http response with another custom response. 
I'm not talking about manipulating headers only; I want to overwrite the whole 
response.

Thanks,
Seyed

> On Apr 12, 2018, at 8:44 AM, Christopher Faulet <cfau...@haproxy.com> wrote:
> 
>> 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