Sure I am working on a router that is specific to my business. Its job is to make legacy systems "behave" as newer ones. Some protocols will have enough info in headers. These make us happy 😊. There are older arcane legacy protocols that just behave badly. There is no way to upgrade them as the data is being sent by devices in the field. These require some body inspection. Fortunately there body sizes are very small and well ordered/defined.
I want a dsl that finds the_id and looks like:
Url: /ABC/xyz/, use: header inspection a, with params
Url: /DEF/uvw/, use: body dig, params
Url: /GHI/rest/, use: man in the middle, params
...
I need about 40 such lines.
The man in the middle records a new identifier that is later a synonym for the id
You would never design something like this on purpose from scratch, but to "de-snoflake" legacy... The result of this bailing wire is a correct id header so the rest of the system can treat the traffic with normal tools and to encapsulate the legacy packet conversion handling to one place.
These rules cross multiple lua block types form header, body, response, and logging. It seems that it would be DRYer to emit the config from a simple DSL parser. Maybe an include by lua block?
Why do I need funky routing, we're moving to AWS and things that worked in a hand-tossed world could be made way more adaptive and resilient post the lift and shift efforts. But the code on the devices and in the containers is *not* going to change. But, I want to move and balance container loads. Oh, for various reasons we also lose the origin ip.
On 06/18/2018 09:14 PM, Blaine Morgan wrote:
> I was thinking in the init by lua phase.
>
> The languages for templates are not as conducive for building a simple
> DSL so I wanted to use the init_by_lua phase. But in my passes in the
> nginx lua ref I didn't see how to write config
Could you elaborate on what you are trying to accomplish, specifically?
It is unclear. And what do you mean by "the effects are spread across ..."?
The init_by_lua phase runs _during_ the Nginx configuration parsing (or
even after if you have a lua_shared_dict defined), so you have to
manipulate the internal structures maintained by Nginx.
A few months ago, I tried to promote a new way to configure
ngx_lua-specific settings via a new configure_by_lua phase:
https://github.com/openresty/lua-nginx-module/pull/1259
The ultimate goal was to be able to configure server or location blocks
right from within Lua, but as you can see from the thread, it was not
accepted. As of today, you are likely better off with templating your
configuration as suggested by Robert.
Best,
Thibaul.
