WW-4834 fixed faulty regex

[sdutry]

No description provided.

[lukaszlenart]

Could you wait a bit with merging this PR? I have asked somebody to take a look on this.

[sdutry]

Ok,

I will wait.

[atcazzual]

The expression did not seem to work at all until I escaped the slashes, changing / to \/

Once I got it working, there then seems to be a bug in the new expression when matching on URLs that use IP addresses. The grouping has changed causing two problems with matching IP addresses.

1. The dot . character that delimits the octets in an IP address only applies to the last condition, 25[0-5]\. on line 57, instead of all conditions for an IP octet. This makes matching most IP addresses fail. The only IPs that will match would need to have 3-digit octets for the first three where the first two digits are 25. NOTE: This seems to have been resolved by the commit above.
2. The conditions for the last octet are no longer grouped (line 58) making the OR | operator act on what was a higher level group. Because of this, the fourth octet would have to be only one or two digits.

For example, only IPs like the following will pass validation:
http://253.254.255.1 (mostly resolved by the commit above)
http://253.254.255.12 (mostly resolved by the commit above)

After the commit above, any IP with 3 digits in the last octet will not pass validation:
http://1.2.3.100
http://1.2.3.255

[sdutry]

After the commit above, any IP with 3 digits in the last octet will not pass validation

You are right, i forgot the grouping (meaning the or statements mean something completely different), i'll fix this ASAP

The expression did not seem to work at all until I escaped the slashes, changing / to \/

I don't see why this would be. I am not aware that a "/" is a special sign inside a java string or java RegEx. Or is it because this same regex is used in javascript regex validation (where the '/' sign does mean something). I'll change it back ASAP too

[lukaszlenart]

I think we are good here, thanks a lot for yours work :)

[sdutry]

@lukaszlenart
Sorry for breaking it in the first place. That wasn't my intention.

Do you want me to merge this now, or am i still overlooking stuff?

[lukaszlenart]

I would wait a bit and give Adam a chance to post a comment (if he wants to). No rush :)

[atcazzual]

Looks good to me. All matching capabilities from prior to the optimizations seem to be there.