[undertow-dev] Predicate Handlers

[Stuart Douglas]

Anil Saldhana wrote:
> 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)

They are both already taken care of. Boolean operators not, and, or are 
built in (the word form, not !, && and ||). Operator precedence is in 
the order listed and can be overridden with parenthesis.

Stuart

>
> 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
>> etc
>>
>> 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).
>>
>> [1]
>> https://github.com/undertow-io/undertow/tree/master/core/src/main/java/io/undertow/predicate
>>
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev