Additionally, I think you will have to standardize on:
a) operators - words (or you support symbols also). [a and b]  vs [a && b]
b) order of processing. (Mis-configuration may have side effects)

On 05/12/2013 07:17 PM, Stuart Douglas wrote:
A fairly common requirement for web requests is to enable or disable a certain action based on the state of the request. e.g:
- disable compression if the response > 10Mb
- If the user agent is X add header Y
- If the path starts with /private disable caching

To enable us to acomplish this Undertow has the concept of predicates[1], which as you would expect are a function object that takes the exchange as an argument and returns a boolean value.

We also provide boolean operator predicates (and, or, not) that allow you to combine these predicates into arbitrarily complex values. The idea is that if a user want to configure a conditional action on the request they will use these predicates to specify the condition.

To that end we need some way of representing them in the Wildfly configuration file, and so I have hacked up a basic syntax to configure them, and I would like some feedback. The configuration syntax will written directly into the standalone.xm and jboss-web.xmll to conditionally enable handlers.

A basic example looks like:
path["/MyPath"] or (method[value="POST"] and not requestHeadersPresent[value={Content-Type, "Content-Encoding"}, ignoreTrailer=true] )                                                                               
The following boolean operators are built in, listed in order or precedence:                                                              
- not                                                                                                                                     
- and                                                                                                                                     
- or     
They work pretty much as you would expect them to. All other tokens are taken                                                             
to be predicate names. If the predicate does not require any parameters then the                                                          
brackets can be omitted, otherwise they are mandatory.                                                     
If a predicate is only being passed a single parameter then the parameter name can be omitted.                                            
Strings can be enclosed in optional quotations marks, and quotation marks can be escaped using \"                                                                                                                      
Array types are represented via a comma separated list of values enclosed in curly braces.

Predicate definitions themselves are loaded via a service loader mechanim, with the service implementation specifying the name and the parameter types.

I would be interested to hear what people think. At the moment this is very simple, however a by product of this simplicity is that you need multiple predicates to handle similar things (e.g. requestHeadersPresent, responseHeadersPresent, requestHeaderContains, requestHeaderEquals etc).