sub probe_resp - VIP RFC

[Dridi Boukelmoune]

> # Why?

No opinion on the why, I get the point and I see the benefits but no
opinion. It also leaves out the non-VBE backends, although as of today
I m only aware of Martin's fsbackend implementation of an out-of-tree
backend.

> * Add a default vcl_probe_resp sub to the builtin.vcl which implements the
>   current behavior. Probes without an explicit response sub definition will
>   use vcl_probe_resp

I'd rather have vcl_probe_response, akin to existing v_b_r.

> * in probe_resp context, make the following objects available
>
>   - analogous to beresp
>
>         - prresp.backend
>         - prresp.http.*
>         - prresp.proto
>         - prresp.status
>         - prresp.reason

Why not beresp? It's a response from the backend, I don't think
reusing the name would be confusing.

> * a probe_resp sub may return with the following
>
>         healthy
>         sick

Or we could reuse "ok" and the universal "fail" like in vcl_init.

> * The default vcl_probe_resp:
>
>         sub vcl_probe_resp {
>                 if (prresp.proto ~ "^HTTP/\d+\.\d+$" &&

^HTTP/1\.[01]$

Dridi