Re: svn commit: r1738292 - /httpd/httpd/branches/2.4.x/STATUS
On Fri, Apr 8, 2016 at 6:25 PM, Eric Covener wrote: > On Fri, Apr 8, 2016 at 6:32 PM, William A Rowe Jr > wrote: > > 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 seems to work inside a directive handler on unix and ends up in > the console: > >ap_log_perror(APLOG_MARK, APLOG_STARTUP, 0, cmd->pool > While it works on windows, this error is logged to the event log (while on unix for a service, it should wind up in the syslog). Not sure if that is entirely simple for the user to observe.
Re: svn commit: r1738292 - /httpd/httpd/branches/2.4.x/STATUS
On Fri, Apr 8, 2016 at 6:32 PM, William A Rowe Jr wrote: > 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 seems to work inside a directive handler on unix and ends up in the console: ap_log_perror(APLOG_MARK, APLOG_STARTUP, 0, cmd->pool > > 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. That's fair, I don't remember if I intentionally or unintentionally didn't propose it immediately.
Re: svn commit: r1738292 - /httpd/httpd/branches/2.4.x/STATUS
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, 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 > > >
