Question: Do you like how your current mapping configuration works, or would you like anything changed about it? i.e. if you could have it ANY WAY YOU WANT with your web server, how would it be? Just like it is now?
One thing to consider: do you pre-generate this config and then reload it when any of those half-million-lines change, as a stopgap for a static config? (In other words, are you using this huge static config in place of a dynamic config?) Would you rather this mapping be dynamic? If so, how would you like it to work?
But if all things are to stay the same, this will be very straightforward and I can have this done by the end of the week.
Well as the map implementation looks quite fast it would be okay for me to have it as it is in nginx. We pre-generate the map file and run a nginx reload as there is no service interruption at reload time.
Cool, I’m working on this today. I’m going to first implement the map module with similar functionality so that you can keep your existing processes and so other users can migrate more easily. But I’m still interested in doing the mapping “better” in v2, since making your web server config a read-only database seems like a bit of a hack around lack of dynamic logic.
Yes, I agree – but what specifically would work best with your setup?
In summary the map directive can be used to check some http-header, methodes and a lot more and set the variable to the defined value.
In the original use case we change the root line dynamically like this root /web/data/data$storageid; . Is this possible in Caddyserver v1 or v2 to change the root dynamically as I haven’t seen it in the doc if it’s possible or not https://caddyserver.com/docs/root ?
The nice part with the map and nginx is that the variables and directives are evaluated at request time is this also possible in Caddyserver v1 or v2?
I’m not sure I follow as to why the map is more generic, what do you mean? The structure I proposed also sets variables which can be used in other places. (That’s why I intended with "map_vars" - did you see that?)
Soon, yeah! It’s going to take a backseat to fastcgi at this point (which is my next big project starting monday), but I’ll get to work on it sooner or later, or when I have a few minutes here and there.