1) It it were configurable, in certain places it makes sense to use
space as a separator (e.g. in IP addresses).
-> any whitespace? -> \w+ and we end up with using a regex to split a
list of regexes.
2) It might make sense to require regex expressions to be surrounded by '/'.
E.g. "/192\.168\.1\.\d{1,3}/" is a regex, but "192.168.1.17" is a literal value.
3) I wonder if it makes sense to manipulate RequestFilterValve though
JMX. E.g. to add/remove some filtering patterns at runtime.
Mark, are there other places than RequestFilterValve and its
subclasses (RemoteAddrValve, RemoteHostValve) where you are planning
this change?
There this feature can be configurable. E.g. if split='' then
splitting is not performed at all. I do not see why we should force
users to use a single regex only.
Having a single regex by default is OK with me, but forcing a single
regex saves too little in performance of
RequestFilterValve.process(..) (removes iterating over an array but
adds a null check).
[OT] Merry X'mas
Best regards,
Konstantin Kolinko
2010/12/25 Tim Funk <funk...@apache.org>:
> +0.5 - I wonder if in some cases - it may be preferable to use a property
> called split which lets the user define the separator which we can pass to
> String.split(). [Which OTOH may be more confusing (yet powerful) since the
> user is using a regex to split get a list of regex]
>
> -Tim
>
> On 12/24/2010 1:34 PM, Mark Thomas wrote:
>>
>> There are a number of configuration properties defined as "comma
>> separated regular expressions". As someone pointed out at at ApacheCon
>> that is a little odd. It stops "," being used in an expression and is
>> inefficient.
>>
>> Having just been bitten by this while setting up the new Jira instance,
>> I intend change all properties that take regex in Tomcat 7 to use a
>> single regex. This will simplify the code, simplify configuration and
>> make the regex processing faster.
>>
>> I probably won't get around to actually doing this until the new year.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
