On 27.12.2010 21:22, Christopher Schultz wrote:
So the plan would be to have users convert values like this:
127\.0\.0\.1, 10\.10\.10\.1, 192\.168\.1\.[0-9]+
to this:
(127\.0\.0\.1|10\.10\.10\.1|192\.168\.1\.[0-9]+)
which is equivalent to
127\.0\.0\.1|10\.10\.10\.1|192\.168\.1\.[0-9]+
if we do not want to reference the resulting matches.
One way to get rid of the dot escaping would be
^(127.0.0.1|10.10.10.1|192.168.1.[0-9]+)$
because the verbatim dots in the IP addresses can only match the any
char dot in that expression.
3. Please make it clear, on a per-attribute basis if appropriate,
whether the pattern will implicitly use start-of-input and end-of-input
markers on the ends. I've been bitten several times by the operational
differences between using Matcher.matches (which is implicitly "^...$")
and Matcher.find/Matcher.replaceAll. Presumable, we'll be using
Matcher.matches and therefore ^...$ is not necessary in any values being
provided by the user: please just state that explicitly.
+1
4. Please ensure that the documentation clearly reminds readers (in each
attribute, rather than requiring the reader to go to a unified short
blurb about regular expressions) that a "." is "anything" and not just a
dot. Lots of (otherwise) smart people often write regular expressions
for IP addresses like this: 10.10.1.1.
... which can be OK, see above.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
