Hi Rajat,
On Fri, May 09, 2014 at 02:13:47PM -0400, Rajat Chopra wrote:
> > Why don't you run that based on ACLs if you're certain that service2 will
> > not cause any trouble ?
> >
> > Eg:
> >
> > use_backend bk_%[hdr(host),host_to_backend.mapfile]_%[path] if {
> > path_beg
> > /service2 }
> > use_backend bk_%[hdr(host),host_to_backend.mapfile]
> >
> > But again, that requires that you know the exhaustive list of valid paths
> > for
> > service2. I don't know if that's your case or not, but that could be the
> > solution.
>
> Yes. Thats the only solution I could come up with. I would have the
> exhaustive list as the script generates the config file, but I worry that
> with 150k backends, what if each backend comes up with its own unique
> path_beg requirement. It would defeat the purpose of the map.
Yeah for sure.
> Also. In this statement (use_backend
> bk_%[hdr(host),host_to_backend.mapfile]_%[path] if { path_beg /service2 })
> using _%[path] is not good, right? We need to use
> 'bk_%[hdr(host),map(mapfile)]_service2', right?
Indeed good point.
> 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!
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!
Regards,
Willy
