Re: svn commit: r1777998 - /httpd/httpd/branches/2.2.x/STATUS
As this seems (once applied to 2.4) to be an accepted part of the overall patch, Yann you might want to add this to the merge/backport patch branches as part of our overall, recommended patches against 2.2/2.4. On Mon, Jan 9, 2017 at 9:53 AM, wrote: > Author: wrowe > Date: Mon Jan 9 15:53:52 2017 > New Revision: 1777998 > > URL: http://svn.apache.org/viewvc?rev=1777998&view=rev > Log: > Reviewed and approved, because 2.2.x is not likely to have another bugfix > release beyond security fixes. > > For the same reason, demote months-old proposal to stalled, as this is not > likely to gain another reviewer. > > > Modified: > httpd/httpd/branches/2.2.x/STATUS > > Modified: httpd/httpd/branches/2.2.x/STATUS > URL: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=1777998&r1=1777997&r2=1777998&view=diff > == > --- httpd/httpd/branches/2.2.x/STATUS (original) > +++ httpd/httpd/branches/2.2.x/STATUS Mon Jan 9 15:53:52 2017 > @@ -102,9 +102,20 @@ RELEASE SHOWSTOPPERS: > PATCHES ACCEPTED TO BACKPORT FROM TRUNK: >[ start all new proposals below, under PATCHES PROPOSED. ] > > + *) http: allow folding in check_headers(), still compliant with RFC 7230 > (3.2.4). > + trunk patch: http://svn.apache.org/r1777460 > + http://svn.apache.org/r1777672 > + 2.4.x patch: N/A > + 2.2.x patch: > http://home.apache.org/~ylavic/patches/httpd-2.2.x-r1777460-v3.patch > + (needed because of s/APLOGNO//) > + +1: ylavic, covener, wrowe > + > PATCHES PROPOSED TO BACKPORT FROM TRUNK: >[ New proposals should be added at the end of the list ] > > + > +PATCHES/ISSUES THAT ARE STALLED: > + >*) mod_proxy_connect: The connect method doesn't work if the client is > connecting to the apache proxy through an ssl socket. Fixed. > [Brad Boyer, Mark Cave-Ayland, Julian Gilbey, Fabrice Durand, > @@ -126,16 +137,6 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: > the new code would be now very closed to 2.4.x's, might be > worth it for (one of) the latest 2.2.x release, and RIP... > > - *) http: allow folding in check_headers(), still compliant with RFC 7230 > (3.2.4). > - trunk patch: http://svn.apache.org/r1777460 > - http://svn.apache.org/r1777672 > - 2.4.x patch: N/A > - 2.2.x patch: > http://home.apache.org/~ylavic/patches/httpd-2.2.x-r1777460-v3.patch > - (needed because of s/APLOGNO//) > - +1: ylavic, covener > - > -PATCHES/ISSUES THAT ARE STALLED > - > * mod_proxy_balancer: Always initialize the shared parameters of a load > balancer member, even if it is already used as standalone. PR 57067. > 2.2.x patch: > http://people.apache.org/~ylavic/httpd-2.2.x-mod_proxy_balancer-lbfactor.patch > >
Re: Build-tree testing is now in trunk
On 01/09/2017 01:27 PM, Jacob Champion wrote: However, if there is agreement that the -V behavior should not be changing between static and dynamic MPM configurations, this would be a good motivation to fix that. ;D Hmm, this is probably a much harder problem than it appeared at first glance, given the large number of directives we'd need to parse to figure out which MPM module is being loaded... Probably worth it to just work around the warning for now with an explicit ServerName. --Jacob
Re: Build-tree testing is now in trunk
On 01/09/2017 01:14 PM, Yann Ylavic wrote:
I'm very sorry about my bad testing, this time I forgot "svn up"!
I really thought I started with it...
No problem! Glad it's working for you now.
Modulo some "Config variable ${DOCROOT} is not defined"
I get that too; it's not a new behavior AFAIK.
and the ServerName warnings, it works now.
I guess we have to do something for the latter, because we can't
change some file (like the $prefix's httpd.conf with the "legacy"
method) to avoid it, right?
We can work around it if it gets annoying enough (by uncommenting the
current ServerName line in the generated conf file, as you've pointed
out in your followup). However, if there is agreement that the -V
behavior should not be changing between static and dynamic MPM
configurations, this would be a good motivation to fix that. ;D
--Jacob
Re: Build-tree testing is now in trunk
On Mon, Jan 9, 2017 at 10:14 PM, Yann Ylavic wrote: > > I guess we have to do something for the latter, because we can't > change some file (like the $prefix's httpd.conf with the "legacy" > method) to avoid it, right? Usually a simple "ServerName localhost" in the main server is enough for me to resolve the warnings, so couldn't we set/force it the generated check/conf/httpd.conf?
Re: Build-tree testing is now in trunk
On Mon, Jan 9, 2017 at 9:42 PM, Yann Ylavic wrote:
> On Mon, Jan 9, 2017 at 8:25 PM, Jacob Champion wrote:
>> On 01/06/2017 04:51 PM, Jacob Champion wrote:
>>>
>>> Hmm, I haven't tested with dynamic MPM modules; I bet the in-tree 'find'
>>> invocation is looking in the wrong place or something.
>>
>>
>> Yep, copy-paste error meant that it was looking in the modules/ build
>> directory instead of server/. Sync up trunk and give it another try.
>
> Nope, still:
I'm very sorry about my bad testing, this time I forgot "svn up"!
I really thought I started with it...
Modulo some "Config variable ${DOCROOT} is not defined" and the
ServerName warnings, it works now.
I guess we have to do something for the latter, because we can't
change some file (like the $prefix's httpd.conf with the "legacy"
method) to avoid it, right?
Sorry and thanks again Jacob.
Re: Build-tree testing is now in trunk
On 01/09/2017 12:42 PM, Yann Ylavic wrote: On Mon, Jan 9, 2017 at 8:25 PM, Jacob Champion wrote: On 01/06/2017 04:51 PM, Jacob Champion wrote: Hmm, I haven't tested with dynamic MPM modules; I bet the in-tree 'find' invocation is looking in the wrong place or something. Yep, copy-paste error meant that it was looking in the modules/ build directory instead of server/. Sync up trunk and give it another try. Nope, still: Did you re-run configure? The fix is to the generated Makefile, which needs to be refreshed. If you did that already, can you send me your Makefile and the location of your MPM DSOs? --Jacob
Re: Build-tree testing is now in trunk
On Mon, Jan 9, 2017 at 8:25 PM, Jacob Champion wrote: > On 01/06/2017 04:51 PM, Jacob Champion wrote: >> >> Hmm, I haven't tested with dynamic MPM modules; I bet the in-tree 'find' >> invocation is looking in the wrong place or something. > > > Yep, copy-paste error meant that it was looking in the modules/ build > directory instead of server/. Sync up trunk and give it another try. Nope, still: $ make check [...] ulimit -c unlimited; /usr/bin/perl /home/yle/src/apache/asf/httpd/test/framework/trunk/t/TEST -config httpd: Syntax error on line 66 of /home/yle/src/apache/httpd/trunk/check/conf/httpd.conf: LoadModule takes two arguments, a module name and the name of a shared object file to load it from With: 66 LoadModule mpm_event_module 67 #LoadModule mpm_motorz_module 68 #LoadModule mpm_prefork_module 69 #LoadModule mpm_simple_module 70 #LoadModule mpm_worker_module Thanks for dealing with all this!
Re: Build-tree testing is now in trunk
On 01/06/2017 04:51 PM, Jacob Champion wrote: Hmm, I haven't tested with dynamic MPM modules; I bet the in-tree 'find' invocation is looking in the wrong place or something. Yep, copy-paste error meant that it was looking in the modules/ build directory instead of server/. Sync up trunk and give it another try. Also: when MPM DSOs are enabled, it looks like the -V option for httpd runs a full configuration check... which means we have to make dummy directories for htdocs/ and logs/ even though they're never going to be used. This is kind of annoying, but the latest trunk patch has a fix for that too. More annoying is that -V is re-run for every single test module, so I get the "need to set a ServerName" warning sprayed across every line of the test suite output when testing with MPM DSOs. This is not new behavior as far as I can tell (it works the same way when testing against an installed server), so I guess you're used to it already. It Would Be Nice (tm) if we didn't run a full sanity check during -V. Thanks again for testing this out! --Jacob
Re: [VOTE] Release httpd-2.2.32
On Mon, Jan 9, 2017 at 1:21 PM, William A Rowe Jr wrote: > +/-1 > [ ] Release 2.2.32 as legacy GA +1 AIX/xlc/ppc64 100% pass (got a little head start when the zips first hit) -- Eric Covener cove...@gmail.com
[VOTE] Release httpd-2.2.32
The pre-release candidate tarballs of Apache legacy httpd 2.2.32 can be found in; http://httpd.apache.org/dev/dist/ Thanks to all for patches and reviews to get us to this point. STATUS file is updated to reflect end of maintenance Jul 1 '17. Your votes, please? +/-1 [ ] Release 2.2.32 as legacy GA Note .tar contains apr 1.5.2, apr-util 1.5.4 while -win32-src.zip also contains apr-iconv 1.2.1, in keeping with 2.2 conventions. New language in INSTALLING and additional language in the Announcement will warn users away from the also bundled PCRE and Expat sources, in favor of current releases.
AW: RemoteIPProxyProtocol
> -Ursprüngliche Nachricht- > Von: Jim Jagielski [mailto:j...@jagunet.com] > Gesendet: Montag, 9. Januar 2017 15:50 > An: httpd > Betreff: RemoteIPProxyProtocol > > Once we backport to 2.4, it will be nigh-impossible to change > the name... > > As we *sure* we want to call it RemoteIPProxyProtocol instead > of just "regular" ProxyProtocol ? > > The latter just sounds and looks "more right" to me. +1 to RemoteIPProxyProtocol Regards Rüdiger
RemoteIPProxyProtocol
Once we backport to 2.4, it will be nigh-impossible to change the name... As we *sure* we want to call it RemoteIPProxyProtocol instead of just "regular" ProxyProtocol ? The latter just sounds and looks "more right" to me.
Re: clang-analyzer?
On 08 Jan 2017, at 4:45 AM, Leif Hedstrom wrote: > I ran clang-analyzer against the HTTPD master branch, and it found 126 > issues. Many of these are benign, but I was curious if the community has any > thoughts on this? With another project, I’ve found that keep static code > analysis to zero issues can really help finding new, serious issues > (basically, we put the tree in failed state if there’s a new static code > analysis issue). > > The issues are all over the source code, in core and mod_’s alike. It’d be > pretty tedious to file individual tickets for each of them, so curious if > there’s any interest in cleaning this up to start with a clean state? It’d > then be easy to add clang-analyzer to the release process for example. Adding clang-analyzer to a make target (not a default part of the build) would be a good step, it would make it easy for anyone to run it if they had it available. The most effective contributions would be patches to fix each one. From experience it is difficult to fix these sort of things without the ability to rerun the analyser to ensure the issue is gone, and every now and again issues uncover things that may take some time to fix. Agreed that getting these things to zero would be a good thing to have. Regards, Graham — smime.p7s Description: S/MIME cryptographic signature
