In this repo which Fiber web framework claims it has a faster path matching over regexp, how would this benefits Caddy if assuming we could have a matchpath directive for template and upstream/downstream/backends?
It doesn’t do everything the path matcher does (* in any position) and doesn’t do everything the path_regexp matcher does either (arbitrary regexp not limited to matching individual path segments).
If we were to add support for something like that, I think it would need to be a new matcher, maybe called path_segments or something. A plugin could easily add support for that!
Great, having that as a plugin would be great for performance?
Honestly, you should only worry about the performance if you have a very high traffic server. I don’t think it’ll make a huge difference otherwise to just use a regexp.
1 Like
This follows a similar kind of pattern that I’ve seen some common Golang request routers utilize.
They do tend to be pretty quick, but they’re also limited to a fairly narrow band of functionality. Strictly speaking both Caddy’s normal matching (with wildcards) and regex matching are more versatile, but I don’t doubt the above will have an edge over regex matching while still being able to pull those matches out for use elsewhere.
Maybe this would work well as a third party matcher module? Extending Caddy — Caddy Documentation
Welcome @jameszen2020 –
I’m sure that if someone determined path matching was their bottleneck (in an extremely layered and complex system with tons of I/O and system calls which are actually bottlenecks), something like that could be helpful, sure.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.