On Fri, Oct 14, 2011 at 2:34 PM, Stefan Fritsch <[email protected]> wrote:
> > > In pre-2.4, it seems we could be more tolerant than 10 subs or 8K > > if we're going to be returning a NULL that's never been returned > > in practice. > > Introducing an arbitrary length limit seems pretty invasive for 2.2.x. > > > Btw, isn't the nmatch the number of () pairs in the regex? If so, then > enforcing the AP_MAX_REG_MATCH limit could introduce behaviour change > in existing configs: Previously, ap_pregsub on with a regex with more > than 10 capturing () pairs would replace $1 ... $9 with the first nine > matches. But now, it would just return the original string. is there some other reasonable way we can return an error or avoid the problem besides returning the original string? I would prefer that we continue to replace $1 ... $9 in the error case in 2.2.x. > > Also, just returning the original string does not allow to detect > errors. Currently ap_pregsub in 2.2.x always succeeds in that it > replaces $1 to $9. I am against changing this in a way that may return > the unchanged string. Maybe it would be more appropriate to enforce > AP_MAX_REG_MATCH at compile time in ap_regcomp()? Then the errors > would be more obvious to the user. > the latter sounds good. I doubt that very many admins have legitimate use cases for more than AP_MAX_REG_MATCH matches. Greg
