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 <server ip>:<port>ssl crt <certificate path> no-sslv3 
> > no-tlsv10 ciphers <cipher>
> >     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

Reply via email to