On Tue, Oct 29, 2019 at 12:40:52AM +0100, Aleksandar Lazic wrote:
> > 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 }
>
> Looks good but 'deny' and '200' feels wrong.
>
> Maybe we should have a 'http-request monitor ...' which replaces the monitor*
> stuff?
Well, guys you convinced me for monitor-uri. We still don't have the
"return" directive which would have been more suitable for this, but
in any case I agree that transcoding the monitor-fail rules to anything
else will be painful.
Also, the code dealing with monitor-uri isn't the ugliest one as it's
still handled by the streams and could be converted to HTX lately. It's
just that seeing it being tested in the CLI code irritates me a little
bit.
However, for "mode health" and "monitor-net", it's another story and
these ones cannot work in SSL nor with muxes :-/
To give you an idea, this is what we have in the FD accept code :
if (p->mode == PR_MODE_HTTP ||
(p->mode == PR_MODE_HEALTH && (p->options2 & PR_O2_CHK_ANY) ==
PR_O2_HTTP_CHK))
send(cfd, "HTTP/1.0 200 OK\r\n\r\n", 19,
MSG_DONTWAIT|MSG_NOSIGNAL|MSG_MORE);
else if (p->mode == PR_MODE_HEALTH)
send(cfd, "OK\n", 3, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_MORE);
Sending these ones raw on the socket with SSL or H2 makes no sense, and
I'd rather stop hacking the socket at this level. That's why I'm really
impatient to drop these ones.
Thanks,
Willy
