Feedback needed: vmod_reqwest

[Dridi Boukelmoune]

On Sun, Jul 3, 2022 at 3:16 PM Guillaume Quintard
<guillaume.quintard at gmail.com> wrote:
>
> Hi all,
>
> In January, I wrote here about vmod_reqwest and today I'm coming back with a major update and a request for the community.
>
> Little refresher for those who don't know/remember what vmod_request is about: https://github.com/gquintard/vmod_reqwest.
> In short it does dynamic backends and HTTP requests from VCL (à la vmod_curl).
> Some random buzzwords to make you click on the link: HTTPS, HTTP/2, gzip, brotli, parallel requests, sync/async, cryptocurrency.

I didn't find how to scam people with NFTs in the manual, should I
open a github issue?

> The main benefit of this release is the probe support. vmod_reqwest is now capable of handling probes the same way native backends do, but combined with dynamic backends, it allows you one pretty neat trick: you can probe one backend to set the health of another.
>
> The API is fairly complete and ergonomic I believe, but I would love to get more hands and eyes on this to break it/make it better. If some of you have opinions and/or want to take it for a spin, there are build explanations in the README, as well as a Dockerfile [1] that will build onto the official image without polluting it.
>
> Let me know what you think of it!

I really like the idea of a optional path prefix being automatically
prepended to the value of bereq.url directly at the backend layer
:thumbsup:

In general, I agree, the API looks rather well thought out, even
though it does suffer bloated constructor syndrome. Did you put only
timeout and connect_timeout to lower the number of arguments or
weren't you able to implement ftbo and bbto with reqwest? I suspect
both :p

Also it says this:

> In practice, when contacting a backend, you will need to `unset bereq.http.accept-encoding;`, as Varnish sets it automatically.

Probably a nice spot to mention
https://varnish-cache.org/docs/7.0/reference/varnishd.html#http-gzip-support
to explain why one would be set.

On the other hand, if you disable gzip support you may also be
forwarding the client's accept-encoding header if it survived all the
way to the backend fetch.

I may fork a vext_respounce [1] when extensions become capable of
registering backend implementations ;)

Cheers
Dridi

[1] I won't have time to actually do it