Am 28.10.2019 um 17:43 schrieb David Birdsong:

On Mon, Oct 28, 2019 at 12:27 PM 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.

    Could this work?

        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.


     > On Sat, Oct 26, 2019 at 8:14 AM Willy Tarreau < 
    < <>>> 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 
     >     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 
     >     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

Reply via email to