httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Really big regex results from ap_pregsub
Date Wed, 12 Oct 2011 19:48:32 GMT
It doesn't seem reasonable to wait any longer to take this to dev.
I don't really need to go into the root complaint since this aspect
stands on its own.

On 10/7/2011 3:51 PM, William A. Rowe Jr. wrote:
> On 10/7/2011 7:26 AM, Eric Covener wrote:
>>> It might be sensible to return NULL in this first loop when len exceeds
>>> REALLY_BIG_NUMBER - a few mb?  Not sure.
>> sounds reasonable to me
> Should we tolerate a string longer than our usual 8kb limit?  It's
> not even that big a number.
> Returning NULL ... we would have to make sure all callers are really
> prepared for a NULL.

So the question comes down to what is realistically the absolute max
valuable regex substitution which ap_pregsub() should be allowed to
emit.  I'm in favor of HUGE_STRING_LEN being the abs max result.

Secondly, what action should ap_pregsub take when this absolute max
string size is exceeded?  A sudden switch to returning NULL for these

 * After performing a successful regex match, you may use this function to
 * perform a series of string substitutions based on subexpressions that were
 * matched during the call to ap_regexec
 * @param p The pool to allocate from
 * @param input An arbitrary string containing $1 through $9.  These are
 *              replaced with the corresponding matched sub-expressions
 * @param source The string that was originally matched to the regex
 * @param nmatch the nmatch returned from ap_pregex
 * @param pmatch the pmatch array returned from ap_pregex
AP_DECLARE(char *) ap_pregsub(apr_pool_t *p, const char *input, const char *source,
                              size_t nmatch, regmatch_t pmatch[]);

I found this interesting, too

/** The max number of regex captures that can be expanded by ap_pregsub */
#define AP_MAX_REG_MATCH 10

And what is the behavior of > AP_MAX_REG_MATCH captures?  Perhaps we should
follow that same behavior for > HUGE_STRING_LEN results?

We moved this discussion public to learn of any modules, particularly third
party modules, which are relying on massive string substitutions that could
exceed any new max result string size restrictions.

View raw message