On Mon, May 10, 2021 at 07:59:56AM -0300, Joao Morais wrote:
> Hello again! Here are the snippets running with 2.4-dev18 - docker image
> haproxy:2.4-dev18-alpine:
>
> $ cat h.cfg
> global
> log stdout format raw local0
> lua-load /tmp/h/svc1.lua
> lua-load /tmp/h/svc2.lua
> defaults
> timeout server 1m
> timeout client 1m
> timeout connect 5s
> log global
> listen l
> mode http
> bind :8000
> option httplog
> http-request lua.auth
> http-request use-service lua.send-failure
>
> $ cat svc1.lua
> core.register_action("auth", { "http-req" }, function(txn)
> txn:set_var("txn.code", 401, true)
> end, 0)
>
> $ cat svc2.lua
> core.register_service("send-failure", "http", function(applet)
> response = applet:get_var("txn.code")
> if response ~= nil then
> applet:set_status(response)
> else
> applet:set_status(403)
> end
> applet:add_header("Content-Length", 0)
> applet:add_header("Content-Type", "text/plain")
> applet:start_response()
> end)
>
> Now curl'ing the config above:
>
> $ curl -i localhost:8000
> HTTP/1.1 403 Forbidden
> content-type: text/plain
> content-length: 0
>
> $ curl -i localhost:8000
> HTTP/1.1 401 Unauthorized
> content-type: text/plain
> content-length: 0
>
> The first run is always a 403 which means that the reading of the txn.code
> retuned nil, all the next attempts correctly returns 401. Maybe I'm missing
> some kind of initialization here? Otherwise I'm happy to provide this as a
> GitHub issue.
I can reproduce it. I agree there's something odd, as it means that
there is some random matching or that something is not properly
initialized. I suspect that a vars field isn't properly initialized
somewhere. I'm investigating, thanks for the report!
Willy
