On Mon, Oct 28, Aleksandar Lazic wrote:
> Am 27.10.2019 um 20:16 schrieb David Birdsong:
> > I'm just curious: what replaces monitor-uri? I'm putting up a new proxy
> > tier at my new company and can steer to use the more up-to-date method,
> > but combing the docs and nothing jumps out at me.
> > 
> > I'm guessing something in either http-re{quest,response}, but I don't
> > see anything that synthesizes responses in there.
> 
> I would think about to use errorfile for this.
> 
> https://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4-errorfile
> 
> Could this work?
> 
> ```
> global
>   ...
> default
>   ...
> frontend
>   ...
>   use_backend b_health if { path_beg /health }
>   ...
> 
> backend b_health
>   errorfile 200 /etc/haproxy/errorfiles/200health.http
>   ...
> 
> ```

Or maybe something like:
http-request deny deny_status 500 if { path_beg /health } { nbsrv(yourbackend) 
lt 1 }
http-request deny deny_status 200 if { path_beg /health }

-Jarno

> > On Sat, Oct 26, 2019 at 8:14 AM Willy Tarreau <w...@1wt.eu 
> > <mailto:w...@1wt.eu>> wrote:
> > 
> >     Hi,
> > 
> >     a few months ago while working on cleaning up and stabilizing the
> >     connection layers, I figured that we still have ugly hacks bypassing
> >     the whole stack around the "mode health", "monitor-net" and 
> > "monitor-uri"
> >     directives, that were all used to respond to health checks from an
> >     external LB. Since SSL was introduced, these started not to make much
> >     sense anymore, with raw data being sent directly to the socket and
> >     bypassing the SSL stack, and now with muxes it's even worse.
> > 
> >     Given their obvious obsolescence I don't expect anyone to be using these
> >     anymore and to have switched to other mechanisms like HTTP redirects,
> >     errorfiles or Lua instead which are all way more versatile and
> >     configurable.
> > 
> >     Thus I was thinking about marking them deprecated for 2.1 and then
> >     removing them from 2.3. Or even better, removing them from 2.1, but
> >     since we have not sent a prior deprecation warning, it would really
> >     require confirmation that really nobody is using them at all anymore
> >     (which I think is likely the case starting with 1.5).
> > 
> >     Any opinion on this ?
> > 
> >     Thanks,
> >     Willy
> > 
> 
> 

-- 
Jarno Huuskonen

Reply via email to