Am 28.10.2019 um 17:43 schrieb David Birdsong:
On Mon, Oct 28, 2019 at 12:27 PM Aleksandar Lazic <[email protected]
<mailto:[email protected]>> 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?
Could be, the above was just a brainstorming.
also, what would replace `monitor fail if {stopping}`?
maybe Jarno suggestion is a better way to go.
Regards
Aleks
> On Sat, Oct 26, 2019 at 8:14 AM Willy Tarreau <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> 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
>
