But a list can't be used with a single match operation right? I'm certainly not currently interested in reworking all that logic, so that'd be a blocker.
The lists are groups of URI's to which we are restricting access to certain IP ranges. Currently there's only a single list, and if we want to block a specific page, we update the URI list. If we can use multiple classes, we can update the config at more of an object level rather than individual class entries. So I have a field in another dgl called "uri_dgl" and I could then go from having [code]"uri_dgl" { "permanent_list" }[/code] to [code]"uri_dgl" { "permanent_list temporary_list" }[/code] rather than adding a handful of entries to the "permanent_list" class.
As for size, it's only ever up to say 20 max, and that'd be during an upgrade window. As we sit behind a CDN, our TCP connection count is vastly lower than out HTTP_REQUEST count, so I'd be happy using the CLIENT_ACCEPTED as the periodic cleanup / build mechanism. But is it's just not effifient a thing to do overall, there's clearly no point.
it's not really that important, just a nice to have that would make the solution I've architected easier for our support guys to understand and maintain.