> > > Wonder if we could use some pluggable logic for map. e.g. User can provide > > a > > .so with the user defined map function. So my call will become : > > It's still early to do this, there are strict types on the patterns and > their own alloc/release/insert/delete functions. > > > use_backend bk_%[hdr(host),path,myown_func(path_to_dot_so)] if TRUE > > And at config time, haproxy does a dlopen on path_to_dot_so, and expects > > that > > dlsym finds a myown_func method. One that returns a string when given the > > two > > arguments (host,path). > > It may be useful for other dynamic user defined acls also. > > In practice we should not need to define that many new ACLs since they're > supposed to rely on the sample fetch functions. However, sample fetch > functions can very easily be added. > > > Far fetched feature, eh? :) > > No that much. I'm thinking about something. Maps can retrieve the first > matching prefix using "map_beg". So if you pass "base" to your map, you'll > have the host+path on input, and take the first matching prefix. Thus, it > will give you this : > > use_backend bk_%[base,map_beg(mapfile)] > > The file would contain all the host+path sorted from the longest to the > shortest (basically just a sort -r) : > > domain1/path1/ backend1 > domain1/path2/ backend2 > domain1/ backend3 > domain2/path1/ backend1 > domain2/ backend4 > > The only problem is that the "beg" match needs to iterate over all entries, > so it will be slower than a tree based lookup, but much faster than running > 150k rules! >
That looks great. Humble opinion here, or just my discomfort maybe. The map_beg will certainly solve my current case, but it feels like that a generic user callable function would offload the myriad other cases that might crop up in the future. Pretty sure someone will ask for a map_reg down the line - a map with keys as compiled regexes is compelling. > And further, I think that with some tweeking, we could make the "beg" match > use the longest prefix match function of the ebtrees. I remember that there's > something tricky about it related to the string length, but if we need to pad > with a zero or something like this, it might not be a big deal. So maybe in > the end we could improve the map match to lookup host+uri prefixes faster > than we do today. > > That would be great for URL or Location rewriting! > May I ask about the ETA on this? Greedily, With sincere thanks. Rajat
