It was working, in the sense that it had the intended effect (the [un]define took effect) in the broader global context.
This is a breaking change to some potentially existing configs, however misguided they are, which is the sort of thing we've avoided in the released branch. Could we log an error rather than preventing startup? One issue is that these directives are encountered prior to opening the error log file. One possible fix would be to have a second directive handler with the sole purpose of emitting errors, running at the normal processing scope, and not within exec_on_read. This shouldn't be allowed to fester on trunk, obviously, but for 2.4 it seems like something we shouldn't alter, no matter how much it frustrates users who used this unintentionally. On Fri, Apr 8, 2016 at 2:52 PM, <cove...@apache.org> wrote: > Author: covener > Date: Fri Apr 8 19:52:19 2016 > New Revision: 1738292 > > URL: http://svn.apache.org/viewvc?rev=1738292&view=rev > Log: > confused IRC user hit this in 2.4 > > > Modified: > httpd/httpd/branches/2.4.x/STATUS > > Modified: httpd/httpd/branches/2.4.x/STATUS > URL: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1738292&r1=1738291&r2=1738292&view=diff > > ============================================================================== > --- httpd/httpd/branches/2.4.x/STATUS (original) > +++ httpd/httpd/branches/2.4.x/STATUS Fri Apr 8 19:52:19 2016 > @@ -175,6 +175,15 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: > 2.4.x patch: trunk patch works (compatibility note to be adjusted) > +1: jailletc36 > > + *) core: block Define and Undefine in vhost and directory context. > Because > + it is EXEC_ON_READ, it "breaks out" of these contexts anyway. > + trunk patch: http://svn.apache.org/r1656063 > + http://svn.apache.org/r1656122 > + 2.4.x patch: > http://people.apache.org/~covener/patches/2.4.x-define-limits.diff > + > + +1: covener (I need to review the docs manually in this area) > + > + > PATCHES/ISSUES THAT ARE BEING WORKED > > *) http: Don't remove the Content-Length of zero from a HEAD response if > > >
