[undertow-dev] Predicate Handlers

Stuart Douglas sdouglas at redhat.com
Tue May 14 18:55:52 EDT 2013 

I think your example of config is a better, I was just trying to show 
the general idea.

I think we only need to support this for 'filter' handlers (i.e. 
handlers that appear in the middle of a handler chain) anyway, having a 
condition on a handler at the end of the chain makes no sense, as there 
is no later handler to serve the request.

Stuart

Tomaz Cerar wrote:
> I like general idea but not the place where I configure it, at least based
> on sniplet below.
> <handlers>  part of configuration is for defining handlers not for defining
> "flow"
>
> It would make more sense to have predicates defined on level of mapping
> handlers to certain flow then to have predicates defined on handler
> definition.
>
> Idea of configuration on top of my head:
> ---------------
>     <server name="default-server" default-host="localhost"
> servlet-container="blah">
> ....
>          <host name="default-host" alias="localhost, some.host">
>              <location name="/" handler="welcome-content">
>                  <filter-ref name="compression"
> enabled="maxContentSize(10000) and not
> responseHeaderContains[name=Content-Type, value='application/zip']"/>
>         </location>
>          </host>
> ...
> ...
> <filters>
>     <compression name="compression">
>       <bzip enabled="pathMatch[*.js] or pathMatch[*.css]" />
>       <deflate>
>     </compression>
> </filters>
> -----------------
>
> But yet again that would work great for filters such as compression, but
> not so great for "content" handlers.
> This is based on what we currently have in undertow subsystem, only thing
> we would need to add is the predicate support.
>
> For "content" handlers I think your proposal of configuration would be the
> only feasible one.
>
> --
> tomaz
>
>
>> -----Original Message-----
>> From: undertow-dev-bounces at lists.jboss.org [mailto:undertow-dev-
>> bounces at lists.jboss.org] On Behalf Of Stuart Douglas
>> Sent: Monday, May 13, 2013 5:37 PM
>> To: Anil Saldhana
>> Cc: undertow-dev at lists.jboss.org
>> Subject: Re: [undertow-dev] Predicate Handlers
>>
>> This would not be a specific config file, but rather just a line in
>> standalone.xml:
>>
>> <handlers>
>>     <compression enabled="maxContentSize(10000) and not
>> responseHeaderContains[name=Content-Type, value='application/zip']">
>>       <bzip enabled="pathMatch[*.js] or pathMatch[*.css]" />
>>       <deflate>
>>     </compression>
>> </handlers>
>>
>> Stuart
>>
>> Anil Saldhana wrote:
>>> On May 13, 2013, at 6:55 PM, Andrig Miller<anmiller at redhat.com>
> wrote:
>>>>    From the Andiamo perspective, I would not want to see an external
> DRL
>> config file.  That violates one of our very first Andiamo tenants.
>>>> Andy
>>> Ok - if you look at Stuart's original email, it does say Wildfly
> config file for
>> specifying predicates. If you assume that to be in the domain model, the
>> specification of the predicates via DRL, can be done in the domain
> model. I am
>> just wondering if the use case is large enough to warrant a rules
> engine. If yes,
>> then drools core will save time.
>>> But from Stuart's response, use case is not large enough to require
>>> rules engine. I withdraw my suggestion. :)
>>>
>>>
>>>> ----- Original Message -----
>>>>> From: "Anil Saldhana"<asaldhan at redhat.com>
>>>>> To: "Stuart Douglas"<sdouglas at redhat.com>
>>>>> Cc: undertow-dev at lists.jboss.org
>>>>> Sent: Monday, May 13, 2013 5:28:03 PM
>>>>> Subject: Re: [undertow-dev] Predicate Handlers
>>>>>
>>>>> You definitely need the predicates. Thinking along First Order
>>>>> logic, I am wondering if this is just an use case for rules
>>>>> definition and processing - something drools has been doing for
> years.
>>>>> Maybe all you need is Drools core lite (or whatever you want to call
>>>>> the core rules processing framework) and one DRL external config
>>>>> file.
>>>>>
>>>>> On May 13, 2013, at 5:41 PM, Stuart Douglas<sdouglas at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> I think you may have missed the point.
>>>>>>
>>>>>> Undertow uses handers, which are conceptually similar to valves,
>>>>>> and you can still provide a custom handler to run any custom code
>>>>>> you want.
>>>>>>
>>>>>> The idea of predicates is that often you will only want a handler
>>>>>> to be applied in a certain situation. So with the case of the
>>>>>> compression handler there may a number of things that may determine
>>>>>> if a request is compressible or not, including:
>>>>>> - content-type
>>>>>> - size
>>>>>> - request path
>>>>>> - cache control headers etc
>>>>>> - accept-encoding (although this has to be handled by the
>>>>>> compression handler to make sure the correct encoding is selected)
>>>>>>
>>>>>> Without something like predicates we have to figure out what all
>>>>>> these criteria are and code them into our handler, and then provide
>>>>>> so means of configuring them. With predicates the compression
>>>>>> handler just worries about compression, and the predicate handler
>>>>>> deal with if the request is compressible or not.
>>>>>>
>>>>>> Also it is possible to provide custom predicates, so with this
>>>>>> approach you can use custom code to decide if an existing handler
>>>>>> should be run without having to modify or extend the handler.
>>>>>>
>>>>>> Stuart
>>>>>>
>>>>>>
>>>>>> Bill Burke wrote:
>>>>>>> IMO, you'd be better off providing a Valve architecture instead of
>>>>>>> maintaining an expression language.  I think you'll often hit a
>>>>>>> scenario where the expression language isn't adequate enough and a
>>>>>>> user will need to write code anyways.  Plus a config-file
>>>>>>> expression language can't be compiler checked.
>>>>>>>
>>>>>>> On 5/12/2013 8: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
>>>>>> _______________________________________________
>>>>>> undertow-dev mailing list
>>>>>> undertow-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev

More information about the undertow-dev mailing list