On Mon, Oct 28, 2019 at 12:27 PM Aleksandar Lazic <al-hapr...@none.at>
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
> ...
>
> ```
>
my understanding is that errorfile <code> <file> just sets the full http
response for a given synthesized code, but doesn't actually cause haproxy
to not send to a backend server and return the value for the code specified.
woudn't this return a 503, "no servers" response?
also, what would replace `monitor fail if {stopping}`?
>
> Regards
> Aleks
>
> > 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
> >
>
>
