On Wed, Oct 11, 2017 at 5:15 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: >> >> +#define NOT_IN_PROXY 0x40 /**< Forbidden in <Proxy> */ >> +/** Forbidden in >> <Directory>/<Location>/<Files><If><Proxy>*/ >> +#define NOT_IN_DIR_LOC_FILE >> (NOT_IN_DIRECTORY|NOT_IN_LOCATION|NOT_IN_FILES|NOT_IN_PROXY) >> +/** Forbidden in >> <VirtualHost>/<Limit>/<Directory>/<Location>/<Files>/<If><Proxy>*/ >> #define GLOBAL_ONLY >> (NOT_IN_VIRTUALHOST|NOT_IN_LIMIT|NOT_IN_DIR_LOC_FILE) > > Reviewing this in much more depth yesterday ... this doesn't seem > to be a minor MMN bump, so would not be backportable without some > extra heavy lifting on 2.4 interop. > > A module previously compiled against 2.4 would not carry the newly > correct definition of NOT_IN_DIR_LOC_FILE because all previously > compiled modules are missing the 0x40 bit, right?
Hmm, right I suppose. So provided a user updates core to 2.4.thispatch but does not recompile some modules using NOT_IN_DIR_LOC_FILE or GLOBAL_ONLY against it (which is valid), then the new core would allow such defined directives in <Proxy context (looks like the only consequence). That's because in the new ap_check_cmd_context(), this: > + || ((forbidden & NOT_IN_PROXY) > + && ((found = find_parent(..., "<Proxy")) > + || (found = find_parent(..., "<ProxyMatch"))))) { > return apr_pstrcat(cmd->pool, cmd->cmd->name, gt, > " cannot occur within ", found->directive, > "> section", NULL); wouldn't match. Thus, how about if there, for 2.4.x only (i.e. backport patch), we'd instead check for: > + || (((forbidden & NOT_IN_PROXY) > + || (forbidden & NOT_IN_DIR_LOC_FILE) == NOT_IN_DIR_LOC_FILE > + || (forbidden & GLOBAL_ONLY) == GLOBAL_ONLY) > + && ((found = ...) > + || ...))) ? ISTM that it's strictly equivalent, without the compatibility caveat. Does it work for you? > > That would be the definition of an MMN major bump, previously > compiled modules require recompilation. Yeah, we don't want that in 2.4.x, but SSLProxy* directives per <Proxy> sections yes :) At least I am, and will try ;)