Re: Unable to modify haproxy stats url header
On Mon, Oct 16, 2017 at 07:42:11AM +, Suraj Bora -X (surbora - HCL AMERICA INC at Cisco) wrote: > Hi Willy and Lukas, > > Could you please confirm, if we are planning to fix this in near feature. > If yes, please let us know Sure it will be worked on but it's very low priority considering that it has been working like this for a very long time, that it doesn't create any real trouble and that fixing it might create regressions. > 1. In which build it will be available? No estimate for now. > 2. Are we backporting it to previous builds from which it got removed? Once fixed, and *if the fix presents low risk* then sure, it will be backported. If for any reason you absolutely need to add HTTP headers to a stats response, you can use a workaround consisting in chaining the stats request to a different proxy and having the first one add the headers. Something like this : listen stats_pub bind :1234 mode http http-response add-header foo far server s 127.0.0.1:1235 listen stats_int bind :1235 mode http stats uri / You get the idea. Hoping this helps, Willy
RE: Unable to modify haproxy stats url header
Hi Willy and Lukas,
Could you please confirm, if we are planning to fix this in near feature.
If yes, please let us know
1. In which build it will be available?
2. Are we backporting it to previous builds from which it got removed?
Suraj Bora
surb...@cisco.com
Think before you print.
This email may contain confidential and privileged material for the sole use of
the intended recipient. Any review, use, distribution or disclosure by others
is strictly prohibited. If you are not the intended recipient (or authorized to
receive for the recipient), please contact the sender by reply email and delete
all copies of this message.
http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html
-Original Message-
From: Suraj Bora -X (surbora - HCL AMERICA INC at Cisco)
Sent: 12 October 2017 15:27
To: 'Willy Tarreau' <w...@1wt.eu>; Lukas Tribus <lu...@gmx.net>
Cc: haproxy@formilux.org
Subject: RE: Unable to modify haproxy stats url header
Hi Lukas, Willy,
Thanks for confimation.
We are running some security scan on haproxy urls and found that Ha-proxy
status URL has following vernability:
1. Cacheable SSL Page Found
2. Missing HTTP Strict-Transport-Security Header Query
To resolve this we need to update the http response with below parameters
rspadd Cache-Control:\ no-store,no-cache,private rspadd Pragma:\ no-cache
rspadd Strict-Transport-Security:
It will be useful if we have this fucntionality.
Thanks and Regards,
Suraj Bora
surb...@cisco.com
Think before you print.
This email may contain confidential and privileged material for the sole use of
the intended recipient. Any review, use, distribution or disclosure by others
is strictly prohibited. If you are not the intended recipient (or authorized to
receive for the recipient), please contact the sender by reply email and delete
all copies of this message.
http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html
-Original Message-
From: Willy Tarreau [mailto:w...@1wt.eu]
Sent: 11 October 2017 23:27
To: Lukas Tribus <lu...@gmx.net>
Cc: Suraj Bora -X (surbora - HCL AMERICA INC at Cisco) <surb...@cisco.com>;
haproxy@formilux.org
Subject: Re: Unable to modify haproxy stats url header
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
RE: Unable to modify haproxy stats url header
Hi Lukas, Willy,
Thanks for confimation.
We are running some security scan on haproxy urls and found that Ha-proxy
status URL has following vernability:
1. Cacheable SSL Page Found
2. Missing HTTP Strict-Transport-Security Header Query
To resolve this we need to update the http response with below parameters
rspadd Cache-Control:\ no-store,no-cache,private
rspadd Pragma:\ no-cache
rspadd Strict-Transport-Security:
It will be useful if we have this fucntionality.
Thanks and Regards,
Suraj Bora
surb...@cisco.com
Think before you print.
This email may contain confidential and privileged material for the sole use of
the intended recipient. Any review, use, distribution or disclosure by others
is strictly prohibited. If you are not the intended recipient (or authorized to
receive for the recipient), please contact the sender by reply email and delete
all copies of this message.
http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html
-Original Message-
From: Willy Tarreau [mailto:w...@1wt.eu]
Sent: 11 October 2017 23:27
To: Lukas Tribus <lu...@gmx.net>
Cc: Suraj Bora -X (surbora - HCL AMERICA INC at Cisco) <surb...@cisco.com>;
haproxy@formilux.org
Subject: Re: Unable to modify haproxy stats url header
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
Re: Unable to modify haproxy stats url header
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
Re: Unable to modify haproxy stats url header
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
Thanks Lukas for replay, We have upgraded haproxy with latest build, but still seeing same issue. [root@lb01 ~]# haproxy -v HA-Proxy version 1.5.19 2016/12/25 Copyright 2000-2016 Willy Tarreau <wi...@haproxy.org> Please let us know if we need to verify any configuration. Thanks and Regards, Suraj Bora Dev Cisco Systems, Inc. Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html -Original Message- From: Lukas Tribus [mailto:lu...@gmx.net] Sent: 09 October 2017 23:08 To: Suraj Bora -X (surbora - HCL AMERICA INC at Cisco) <surb...@cisco.com>; haproxy@formilux.org Subject: Re: Unable to modify haproxy stats url header Hello, Am 09.10.2017 um 15:28 schrieb Suraj Bora -X (surbora - HCL AMERICA INC at Cisco): > > > > *We are recently migrated to haproxy 1.5.4 from haproxy-1.5-dev23.3 release, > not seen this issue on same.* > I'm sorry, but 1.5.4 is 3 years old already and contains 183 already fixed bugs: http://www.haproxy.org/bugs/bugs-1.5.4.html Please use a stable and supported release from haproxy.org. Regards, Lukas
Re: Unable to modify haproxy stats url header
Hello, Am 09.10.2017 um 15:28 schrieb Suraj Bora -X (surbora - HCL AMERICA INC at Cisco): > > > > *We are recently migrated to haproxy 1.5.4 from haproxy-1.5-dev23.3 release, > not seen this issue on same.* > I'm sorry, but 1.5.4 is 3 years old already and contains 183 already fixed bugs: http://www.haproxy.org/bugs/bugs-1.5.4.html Please use a stable and supported release from haproxy.org. Regards, Lukas
