Re: HAproxy and lvs

2017-10-11 Thread Aaron West
Hi John,

As mentioned in the previous thread, LVS lives in the Kernel and works
as a router. HAproxy is userspace and a reverse proxy so a completely
different beast! So to answer your question, no it doesn't.

Aaron West

Loadbalancer.org Ltd.

www.loadbalancer.org

+1 888 867 9504 / +44 (0)330 380 1064
aa...@loadbalancer.org

LEAVE A REVIEW | DEPLOYMENT GUIDES | BLOG


On 11 October 2017 at 03:37, John Wei  wrote:
> It seems that HAproxy can also perform TCP load balance.
> Does HAproxy leverage lvs when performing TCP load balance?
>
> John
>



Re: Unable to modify haproxy stats url header

2017-10-11 Thread Lukas Tribus
Hello Suraj, hello Willy,


> frontend stats_proxy
>     bind :ssl crt  no-sslv3 no-tlsv10 
> ciphers 
>     mode http
>     default_backend stats_server
>     rspadd Cache-Control:\ no-store,no-cache,private
>     rspadd Pragma:\ no-cache
>     rspadd Strict-Transport-Security:
>
> backend stats_server
>     mode http
>     option httpclose
>     option abortonclose
>     stats enable
>     stats refresh 60s
>     stats hide-version

rspadd does not work for the stats backend.

This is definitely a change in behavior in 1.5-dev due to 70730ddd
("MEDIUM: http: enable analysers to have keep-alive on stats"):


(from the 70730ddd commit message):
> We ensure to skip filters because we don't want to unexpectedly
> block a response nor to mangle response headers.

Skipping filters causes the behavior reported in this thread.


Do we support this use case though? Do we consider this a regression?
What do you think, Willy?


cheers,
Lukas





Re: Unable to modify haproxy stats url header

2017-10-11 Thread Willy Tarreau
Hi Lukas,

On Wed, Oct 11, 2017 at 06:23:23PM +0200, Lukas Tribus wrote:
> Hello Suraj, hello Willy,
> 
> 
> > frontend stats_proxy
> >     bind :ssl crt  no-sslv3 no-tlsv10 
> > ciphers 
> >     mode http
> >     default_backend stats_server
> >     rspadd Cache-Control:\ no-store,no-cache,private
> >     rspadd Pragma:\ no-cache
> >     rspadd Strict-Transport-Security:
> >
> > backend stats_server
> >     mode http
> >     option httpclose
> >     option abortonclose
> >     stats enable
> >     stats refresh 60s
> >     stats hide-version
> 
> rspadd does not work for the stats backend.
> 
> This is definitely a change in behavior in 1.5-dev due to 70730ddd
> ("MEDIUM: http: enable analysers to have keep-alive on stats"):
> 
> 
> (from the 70730ddd commit message):
> > We ensure to skip filters because we don't want to unexpectedly
> > block a response nor to mangle response headers.
> 
> Skipping filters causes the behavior reported in this thread.
> 
> 
> Do we support this use case though? Do we consider this a regression?
> What do you think, Willy?

Originally it did not work as the stats contents were directly injected into
the response buffer without any analyser, but since we moved it to an applet,
it allowed to support compression and keep-alive, and by extension other HTTP
processing.

I tend to think that if some users rely on this behaviour, we should make
reasonable efforts to try to make it work again. If there's a technical
showstopper, I'm fine with that but I don't have any in mind and I suspect
it's more related to the accidental lack of an analyser flag that nobody
considered worth setting on the response channel when switching to the
stats.

To be honnest, now looking at the code I'm a bit puzzled because I don't
understand anymore either how/when the response analysers needed for the
compression and/or keep-alive are set, or how the AN_RES_HTTP_PROCESS_BE
flag is removed. I'll probably have to check deeper but now this looks
more like an accidental removal.

Thanks,
Willy