Open jszirani opened 4 months ago
Well... I think we're correct here: you've asked for POSIX extended regular expressions which means "leftmost longest" and that rule applies to sub-expressions as well. In this case the matcher finds the match you were expecting first (and this is what is returned had you specified a perl regular expression), then rather than stopping at that point as a perl matcher would do, it backtracks looking for something "better". The first backtrack tries matching with the =?
part matching zero times, and low and behold the [^&]*
then matches to the next &
just like before, only this time it starts further left and so is considered "better". Hope that makes sense!
The issue was found in some custom URL parsing code, I am not sure this is a known issue.
I've isolated the issue to this tiny bit of code:
this will print
0: SERVICE=WMTS 1: SERVICE=WMTS 2: SERVICE 3: =WMTS 4: =WMTS
but I think the last item (number 4) should not have the '=' character present, you can check the regular expression on https://regex-vis.com/ that the = is out of group 4
if you switch to std regex
it will print
0: SERVICE=WMTS 1: SERVICE=WMTS 2: SERVICE 3: =WMTS 4: WMTS