On Tue, May 19, 2020 at 05:39:25PM +0200, Christopher Faulet wrote:
> Le 19/05/2020 à 16:06, Tim Düsterhus a écrit :
> > > 
> > > Now back on topic. Instead of adding more parameters to set_var(), I'd
> > > prefer a warning instead.
> > > 
> > > If someone is using set_var() from Lua, and that variable is never used
> > > or set in the rest of the config, we would know that. Additionally, one
> > > can set "zero-warning" option to prevent abuse by Lua scripts or to
> > > prevent bugs.
> > 
> > This would break my use case for haproxy-auth-request. The plan is that
> > the Lua script unconditionally sets are variable for all response
> > headers and that HAProxy with my patches applied drops the variables
> > that are never going to be read. I specifically want to avoid that the
> > administrator needs to configure the headers to expose. Details are in:
> > https://github.com/TimWolla/haproxy-auth-request/pull/13
> > 
> 
> I agree with Tim. It is pretty handy to let the set_var silently fail. This
> way, a script can expose many variables and let the user choose those he
> needs. The same is already done in the SPOE.
> Then, we've chosen to be backward compatible and let any variable be
> dynamically registered from LUA. There is a warning in the LUA
> documentation. It is now the developers responsibility to be careful. I
> doubt it will be a source of problems. But if so, it could be changed.

Well, it's exactly the same in shell scripts, you set and read variables
and if you misspell them it's the developer's problem. And this is very
convenient and flexible.

Willy

Reply via email to