Am 28.10.2019 um 17:43 schrieb David Birdsong:


On Mon, Oct 28, 2019 at 12:27 PM Aleksandar Lazic <al-hapr...@none.at <mailto: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?

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 <w...@1wt.eu 
<mailto:w...@1wt.eu>
    <mailto: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
     >



Reply via email to