Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Noel Butler]

On 22/03/2016 03:37, Jim Jagielski wrote:

The pre-release test tarballs for Apache httpd 2.4.19 can be found
at the usual place:

http://httpd.apache.org/dev/dist/

I'm calling a VOTE on releasing these as Apache httpd 2.4.19 GA.

[x ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.



Slackware 13.37/14.0/14.1/-current
built with mysql, included APR/APR-Util and ssl



--
If you have the urge to reply to all rather than reply to list, you best
first read  http://members.ausics.net/qwerty/

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Stefan Eissing]

> Am 22.03.2016 um 02:49 schrieb Jan Ehrhardt :
> 
> Jim Jagielski in gmane.comp.apache.devel (Mon, 21 Mar 2016 13:37:40
> -0400):
>> [x] +0: meh
> 
> mod_http2.so will not build 'out of the box' on Windows, because
> mod_http2.dsp is missing
> 
> # Begin Source File
> 
> SOURCE=./h2_ngn_shed.c
> # End Source File
> 

This is indeed missing in mod_http2.dsp... :-(

> This leads to build errors like:
> 
> 1>h2_mplx.obj : error LNK2019: unresolved external symbol
> _h2_ngn_shed_done_task referenced in function _h2_mplx_req_engine_done
> 1>.\Release\mod_http2.so : fatal error LNK1120: 12 unresolved externals
> 
> Moreover, it is confusing that this mod_http2 has version 1.2.8, but is
> different from the v1.2.8 release at
> https://github.com/icing/mod_h2/releases

The version in 2.4.19 of mod_http2 is 1.4.4.

-Stefan

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Jim Jagielski]

Ugg, ugg and triple ugg.

I have a mind to recall 2.4.19, but will leave the vote open
to ensure we don't have problems w/ other platforms before
we re-T&R.

> On Mar 21, 2016, at 9:49 PM, Jan Ehrhardt  wrote:
> 
> Jim Jagielski in gmane.comp.apache.devel (Mon, 21 Mar 2016 13:37:40
> -0400):
>> [x] +0: meh
> 
> mod_http2.so will not build 'out of the box' on Windows, because
> mod_http2.dsp is missing
> 
> # Begin Source File
> 
> SOURCE=./h2_ngn_shed.c
> # End Source File
> 
> This leads to build errors like:
> 
> 1>h2_mplx.obj : error LNK2019: unresolved external symbol
> _h2_ngn_shed_done_task referenced in function _h2_mplx_req_engine_done
> 1>.\Release\mod_http2.so : fatal error LNK1120: 12 unresolved externals
> 
> Moreover, it is confusing that this mod_http2 has version 1.2.8, but is
> different from the v1.2.8 release at
> https://github.com/icing/mod_h2/releases
> 
> Jan
> 

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Stefan Eissing]

Yes, *sad face*.

There was a reason our grandfathers kept everything in one source file...

I added the missing line in trunk and 2.4.x. Jan, are you able
to verify that the current 2.4.x builds for you? Thanks!

-Stefan

> Am 22.03.2016 um 11:25 schrieb Jim Jagielski :
> 
> Ugg, ugg and triple ugg.
> 
> I have a mind to recall 2.4.19, but will leave the vote open
> to ensure we don't have problems w/ other platforms before
> we re-T&R.
> 
>> On Mar 21, 2016, at 9:49 PM, Jan Ehrhardt  wrote:
>> 
>> Jim Jagielski in gmane.comp.apache.devel (Mon, 21 Mar 2016 13:37:40
>> -0400):
>>> [x] +0: meh
>> 
>> mod_http2.so will not build 'out of the box' on Windows, because
>> mod_http2.dsp is missing
>> 
>> # Begin Source File
>> 
>> SOURCE=./h2_ngn_shed.c
>> # End Source File
>> 
>> This leads to build errors like:
>> 
>> 1>h2_mplx.obj : error LNK2019: unresolved external symbol
>> _h2_ngn_shed_done_task referenced in function _h2_mplx_req_engine_done
>> 1>.\Release\mod_http2.so : fatal error LNK1120: 12 unresolved externals
>> 
>> Moreover, it is confusing that this mod_http2 has version 1.2.8, but is
>> different from the v1.2.8 release at
>> https://github.com/icing/mod_h2/releases
>> 
>> Jan
>> 
> 

Re: Proposed change to mpm_register_socket_callback(): apr_socket_t -> apr_pollfd_t

[Jim Jagielski]

> On Mar 15, 2016, at 3:28 PM, Graham Leggett  wrote:
> 
> The trouble with the above is that because of the pool cleanup we now have, 
> pfds[3] needs to live as long as pool p. In your example it does, but there 
> is nothing stopping someone trying to allocate pfds[3] on the stack and then 
> returning. Later the cleanup is run, and boom - difficult to debug crash or 
> weird behaviour.
> 
> With the array you’re guaranteed the memory is allocated from a pool, which 
> means the pool cleanup will always be safe.
> 
> What we should also do is drop the apr_pool_t *p parameter and read it from 
> apr_header_array_t’s pool instead. This will be a further check to stop the 
> caller from doing anything pathological, as we definitely know the cleanup 
> and the array belong to each other, and our API becomes simpler still.
> 
> Attached patch does this.
> 

+1

Re: svn commit: r1734656 - in /httpd/httpd/trunk: ./ include/ modules/http/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

[Rainer Jung]

Am 14.03.2016 um 09:48 schrieb Ruediger Pluem:

On 03/12/2016 01:43 AM, minf...@apache.org wrote:

Author: minfrin
Date: Sat Mar 12 00:43:58 2016
New Revision: 1734656

URL: http://svn.apache.org/viewvc?rev=1734656&view=rev
Log:
core: Extend support for setting aside data from the network input filter
to any connection or request input filter.

Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/include/ap_mmn.h
 httpd/httpd/trunk/include/httpd.h
 httpd/httpd/trunk/include/mpm_common.h
 httpd/httpd/trunk/include/util_filter.h
 httpd/httpd/trunk/modules/http/http_core.c
 httpd/httpd/trunk/modules/http/http_request.c
 httpd/httpd/trunk/server/core.c
 httpd/httpd/trunk/server/core_filters.c
 httpd/httpd/trunk/server/mpm/event/event.c
 httpd/httpd/trunk/server/mpm/motorz/motorz.c
 httpd/httpd/trunk/server/mpm/simple/simple_io.c
 httpd/httpd/trunk/server/mpm_common.c
 httpd/httpd/trunk/server/util_filter.c




This seems to cause frequent (no always) failures with test 8 of t/ssl/proxy.t.


The same here on Solaris 10 Sparc.


The request times out with a 504 status. So it looks like the "backend" in this 
request does not respond.
Used MPM is Event, OS CentOS 6 64 Bit. Without further investigating my 
closeset guess would be that the changes to
checkpipeline cause this.


Regards,

Rainer

Re: svn commit: r1734656 - in /httpd/httpd/trunk: ./ include/ modules/http/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

[Jim Jagielski]

Well, we gotta do something. This is a significant breakage.

> On Mar 15, 2016, at 4:29 AM, Yann Ylavic  wrote:
> 
> On Tue, Mar 15, 2016 at 12:42 AM, Graham Leggett  wrote:
>> On 14 Mar 2016, at 10:48 AM, Ruediger Pluem  wrote:
>> 
>>> This seems to cause frequent (no always) failures with test 8 of 
>>> t/ssl/proxy.t.
>>> The request times out with a 504 status. So it looks like the "backend" in 
>>> this request does not respond.
>>> Used MPM is Event, OS CentOS 6 64 Bit. Without further investigating my 
>>> closeset guess would be that the changes to
>>> checkpipeline cause this.
>> 
>> I commented out check_pipeline() completely, and it passed all the tests.
>> 
>> Looking at check_pipeline, it seems to try and eat trailing CRLFs, which is 
>> duplicating the functionality in read_request_line() which eats preceding 
>> CRLFs already.
>> 
>> check_pipeline() seems to have been overhauled recently, not sure what 
>> problem it is trying to solve. Can we remove it?
> 
> No we can't, or at least we need to eat the trailing CRLFs.
> Otherwise they will be considered as a pipelined request, thus if no
> request is really following, we will block in read_request_line(), w/o
> FLUSHing the previous response.
> For mpm event, that also causes a spurious wake up (defeating
> non-blocking since read_request_line() is/was? blocking).
> 
> But maybe your recent changes could avoid this, dunno, at least we
> need to flush when there is no real pipelined request already there
> (after the CRLFs).
> 
> Regards,
> Yann.

Re: TLS session ticket key (shared) renewal

[Paul Querna]

My thought was to add support for either multiple files, or multiple values
in the existing `SSLSessionTicketKeyFile`.  Then add support to decrypt
from any of the known keys, and have a setting (or the first loaded key)
would be used to encrypt all new keys.  This would allow for rotation in a
reasonable manner.

On Fri, Mar 18, 2016 at 6:55 AM, Yann Ylavic  wrote:

> Currently this can be done by using a (shared) SSLSessionTicketKeyFile
> and gracefuly restarting httpd instances, but there is room for
> improvements here.
>
> Thoughts?
>

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[olli hauer]

On 2016-03-21 18:37, Jim Jagielski wrote:
> The pre-release test tarballs for Apache httpd 2.4.19 can be found
> at the usual place:
> 
>   http://httpd.apache.org/dev/dist/
> 
> I'm calling a VOTE on releasing these as Apache httpd 2.4.19 GA.
> 
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
> 
> Vote will last the normal 72 hrs.
> 
> NOTE: The *-deps are only there for convenience.
> 
> Thx!
> 

Tested on FreeBSD 10.2 with apr-1.5.2, apr-util-1.5.4, nghttp2-1.8.0
- build against openssl-1.0.2 -> mod_http2 OK
- build against libressl-2.2.6 -> mod_http2 OK

[x] +1: Good to go

-- 
olli

Re: svn commit: r1734656 - in /httpd/httpd/trunk: ./ include/ modules/http/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

[Yann Ylavic]

In r1736216, I tried to restore c->data_in_input_filters usage as
prior to r1734656.
Does it help (or I'll revert)?


On Tue, Mar 22, 2016 at 1:02 PM, Jim Jagielski  wrote:
> Well, we gotta do something. This is a significant breakage.
>
>> On Mar 15, 2016, at 4:29 AM, Yann Ylavic  wrote:
>>
>> On Tue, Mar 15, 2016 at 12:42 AM, Graham Leggett  wrote:
>>> On 14 Mar 2016, at 10:48 AM, Ruediger Pluem  wrote:
>>>
 This seems to cause frequent (no always) failures with test 8 of 
 t/ssl/proxy.t.
 The request times out with a 504 status. So it looks like the "backend" in 
 this request does not respond.
 Used MPM is Event, OS CentOS 6 64 Bit. Without further investigating my 
 closeset guess would be that the changes to
 checkpipeline cause this.
>>>
>>> I commented out check_pipeline() completely, and it passed all the tests.
>>>
>>> Looking at check_pipeline, it seems to try and eat trailing CRLFs, which is 
>>> duplicating the functionality in read_request_line() which eats preceding 
>>> CRLFs already.
>>>
>>> check_pipeline() seems to have been overhauled recently, not sure what 
>>> problem it is trying to solve. Can we remove it?
>>
>> No we can't, or at least we need to eat the trailing CRLFs.
>> Otherwise they will be considered as a pipelined request, thus if no
>> request is really following, we will block in read_request_line(), w/o
>> FLUSHing the previous response.
>> For mpm event, that also causes a spurious wake up (defeating
>> non-blocking since read_request_line() is/was? blocking).
>>
>> But maybe your recent changes could avoid this, dunno, at least we
>> need to flush when there is no real pipelined request already there
>> (after the CRLFs).
>>
>> Regards,
>> Yann.
>

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Jacob Perkins]

While we're not an official voter, I did want to advise we’ve tested this 
release on our platform and saw no problems with our high level tests.

> [X ] +1: Good to go


Tested on CentOS 6 x86_64.
—
Jacob Perkins
Product Owner
cPanel Inc.

jacob.perk...@cpanel.net 
Office:  713-529-0800 x 4046
Cell:  713-560-8655

> On Mar 21, 2016, at 12:37 PM, Jim Jagielski  wrote:
> 
> The pre-release test tarballs for Apache httpd 2.4.19 can be found
> at the usual place:
> 
>   http://httpd.apache.org/dev/dist/
> 
> I'm calling a VOTE on releasing these as Apache httpd 2.4.19 GA.
> 
> [X ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
> 
> Vote will last the normal 72 hrs.
> 
> NOTE: The *-deps are only there for convenience.
> 
> Thx!




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Jan Ehrhardt]

Stefan Eissing in gmane.comp.apache.devel (Tue, 22 Mar 2016 11:38:31
+0100):
>I added the missing line in trunk and 2.4.x. Jan, are you able
>to verify that the current 2.4.x builds for you? Thanks!

I did not check the current build, but added the line myself and went
ahead:
https://www.ssllabs.com/ssltest/analyze.html?d=fips.sessiondatabase.net
https://fips.sessiondatabase.net

Server sig: Apache/2.4.19 (Win64) OpenSSL/1.0.2g-fips PHP/5.6.20RC1 (VC11)

There is a VC9 Apache/2.4.19 (Win32) OpenSSL/1.0.2g-fips running as my dev
server on the same machine.
https://tfrtst.sessionportal.net

Jan

Re: svn commit: r1734656 - in /httpd/httpd/trunk: ./ include/ modules/http/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

[Graham Leggett]

On 22 Mar 2016, at 7:11 PM, Yann Ylavic  wrote:

> In r1736216, I tried to restore c->data_in_input_filters usage as
> prior to r1734656.
> Does it help (or I'll revert)?

Got caught up in other stuff before I could get to the bottom of this :(

It looks like we need to restore c->data_in_input_filters usage.

What this c->data_in_input_filters does is do a poor man’s compensation for 
input filters that buffer data during this particular phase of the request 
handling without having a mechanism to tell anybody. Without telling us they’ve 
buffered data, we’ve got to work out ourselves whether we should loop round and 
poll for read, or not. If we make a mistake, we poll for a read that was 
already read, and we hang.

This is really hit and miss - if you have input filters that buffer data in the 
server you’ll hang, but if you don’t have input filters that buffer data in the 
server you don’t hang and the test suite works fine.

When v2.6 comes we must remove c-> data_in_input_filters and use the proper 
mechanism for input filters to signal they have buffered data.

Regards,
Graham
—

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[William A Rowe Jr]

Note that mod_socache_shmcb.c introduced UINT_MAX without
including limits.h... whoops.

Investigating.

On Mon, Mar 21, 2016 at 12:37 PM, Jim Jagielski  wrote:

> The pre-release test tarballs for Apache httpd 2.4.19 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.19 GA.
>
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
>
> Vote will last the normal 72 hrs.
>
> NOTE: The *-deps are only there for convenience.
>
> Thx!
>

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[William A Rowe Jr]

Can anyone get mod_lbmethod_rr.c to build?

I'm seeing 'name' : is not a member of 'proxy_balancer' errors,
as well as ap_proxy_retry_worker() undefined (converted into
an optional function, perhaps?)

On Mon, Mar 21, 2016 at 12:37 PM, Jim Jagielski  wrote:

> The pre-release test tarballs for Apache httpd 2.4.19 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.19 GA.
>
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
>
> Vote will last the normal 72 hrs.
>
> NOTE: The *-deps are only there for convenience.
>
> Thx!
>

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[William A Rowe Jr]

Finally, just confirming we have decided that C99 is now the minimum
supported compiler feature set- used for the vardic macros in h2_filter.c?

On Mon, Mar 21, 2016 at 12:37 PM, Jim Jagielski  wrote:

> The pre-release test tarballs for Apache httpd 2.4.19 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.19 GA.
>
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
>
> Vote will last the normal 72 hrs.
>
> NOTE: The *-deps are only there for convenience.
>
> Thx!
>

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Reindl Harald]

Am 22.03.2016 um 20:55 schrieb William A Rowe Jr:

Can anyone get mod_lbmethod_rr.c to build?


my Fedora 23 rpm-spec builds without any issue or change - most modules 
external sub-apckages and typically used ones static


[root@srv-rhsoft:~]$ /bin/ls -1 /fileserver/yum-repo/fc23/x86_64/ | grep 
mod_

mod_actions-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_asis-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_auth_form-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_authn_anon-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_authn_dbd-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_authn_dbm-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_authn_socache-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_authz_dbd-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_authz_dbm-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_authz_owner-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_buffer-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_cache-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_cache_disk-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_cache_socache-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_cgi-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_data-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_dav-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_dav_fs-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_dav_lock-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_dbd-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_dialup-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_dumpio-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_echo-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_ext_filter-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_file_cache-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_h264_streaming-2.2.7-21.fc23.20160322.rh.x86_64.rpm
mod_heartbeat-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_heartmonitor-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_http2-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_include-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_info-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_lbmethod_bybusyness-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_lbmethod_byrequests-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_lbmethod_bytraffic-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_lbmethod_heartbeat-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_log_debug-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_log_forensic-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_logio-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_macro-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_mime_magic-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_negotiation-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_ajp-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_balancer-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_connect-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_express-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_fcgi-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_fdpass-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_ftp-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_html-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_http-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_scgi-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_proxy_wstunnel-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_reflector-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_request-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_security-2.9.1-2.fc23.20160322.rh.x86_64.rpm
mod_sed-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_slotmem_plain-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_slotmem_shm-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_socache_dbm-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_socache_memcache-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_speling-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_ssl-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_status-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_substitute-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_userdir-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_usertrack-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_vhost_alias-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_watchdog-2.4.19-1.fc23.20160322.rh.x86_64.rpm
mod_xml2enc-2.4.19-1.fc23.20160322.rh.x86_64.rpm



I'm seeing 'name' : is not a member of 'proxy_balancer' errors,
as well as ap_proxy_retry_worker() undefined (converted into
an optional function, perhaps?)

On Mon, Mar 21, 2016 at 12:37 PM, Jim Jagielski mailto:j...@jagunet.com>> wrote:

The pre-release test tarballs for Apache httpd 2.4.19 can be found
at the usual place:

http://httpd.apache.org/dev/dist/

I'm calling a VOTE on releasing these as Apache httpd 2.4.19 GA.

[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.

Vote will last the normal 72 hrs.

NOTE: The *-deps are only there for convenience.

Thx!




signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[William A Rowe Jr]

On Tue, Mar 22, 2016 at 2:58 PM, Reindl Harald 
wrote:

>
> Am 22.03.2016 um 20:55 schrieb William A Rowe Jr:
>
>> Can anyone get mod_lbmethod_rr.c to build?
>>
>
> my Fedora 23 rpm-spec builds without any issue or change - most modules
> external sub-apckages and typically used ones static
>

I don't see where you enabled lbmethod_rr module?

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Eric Covener]

On Tue, Mar 22, 2016 at 3:57 PM, William A Rowe Jr  wrote:
> Finally, just confirming we have decided that C99 is now the minimum
> supported compiler feature set- used for the vardic macros in h2_filter.c?

I don't think that is meant to be bumped. We definitely had simpler
c99-isms fixed in h2.

-- 
Eric Covener
cove...@gmail.com

VOTE RECALLED: (Was: Re: [VOTE] Release Apache httpd 2.4.19 as GA)

[Jim Jagielski]

Due to the Window's build issue, I am recalling this vote.

With http://svn.apache.org/viewvc?view=revision&revision=1736157,
it looks like this issue is resolved. Will give it until 8am
(Eastern) tomorrow and will kick off 2.4.20 T&R

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Reindl Harald]

Am 22.03.2016 um 20:59 schrieb William A Rowe Jr:

On Tue, Mar 22, 2016 at 2:58 PM, Reindl Harald mailto:h.rei...@thelounge.net>> wrote:


Am 22.03.2016 um 20:55 schrieb William A Rowe Jr:

Can anyone get mod_lbmethod_rr.c to build?


my Fedora 23 rpm-spec builds without any issue or change - most
modules external sub-apckages and typically used ones static

I don't see where you enabled lbmethod_rr module?


not sure if my rpm is missing something we don't use

if something was not built then before 2.4.19 because i wrote the SPEC 
file based on the resulting binary modules - just all of them in own 
subpackages and what did not exist at that moment is not missing now


* Fr Jul 10 2015 Reindl Harald 
- update to 2.4.16 (2.4.13, 2.4.14 and 2.4.15 was skipped upstream)
- split modules in own subpackages
- systemd: PrivateDevices=yes
- systemd: RestrictAddressFamilies=~AF_APPLETALK AF_ATMPVC AF_AX25 
AF_IPX AF_NETLINK AF_PACKET AF_X25

- systemd: SystemCallArchitectures=x86-64



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Jeff Trawick]

On Tue, Mar 22, 2016 at 3:55 PM, William A Rowe Jr 
wrote:

> Can anyone get mod_lbmethod_rr.c to build?
>

I guess I'll try soon with cmake on Windows, once prereqs are built and I
add a line or two to CMakeLists.txt for that module :)

(I'm backpedaling to trunk from 2.4.19 after seeing a 2.4.19 mod_http2
build error.)


> I'm seeing 'name' : is not a member of 'proxy_balancer' errors,
> as well as ap_proxy_retry_worker() undefined (converted into
> an optional function, perhaps?)
>
> On Mon, Mar 21, 2016 at 12:37 PM, Jim Jagielski  wrote:
>
>> The pre-release test tarballs for Apache httpd 2.4.19 can be found
>> at the usual place:
>>
>> http://httpd.apache.org/dev/dist/
>>
>> I'm calling a VOTE on releasing these as Apache httpd 2.4.19 GA.
>>
>> [ ] +1: Good to go
>> [ ] +0: meh
>> [ ] -1: Danger Will Robinson. And why.
>>
>> Vote will last the normal 72 hrs.
>>
>> NOTE: The *-deps are only there for convenience.
>>
>> Thx!
>>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1736243 - /httpd/httpd/trunk/modules/cache/mod_socache_shmcb.c

[William A Rowe Jr]

Without objection, I'll be committing the backport in an hr or so for the
morning T&R... this hardly seems to merit a vote, but any objections
are welcome.


On Tue, Mar 22, 2016 at 3:06 PM,  wrote:

> Author: wrowe
> Date: Tue Mar 22 20:06:32 2016
> New Revision: 1736243
>
> URL: http://svn.apache.org/viewvc?rev=1736243&view=rev
> Log:
> Fix missing limits.h header, required for 2.4.next release,
> masked on many platforms by intrinsic limits.h inclusion by
> other headers.
>
>
> Modified:
> httpd/httpd/trunk/modules/cache/mod_socache_shmcb.c
>
> Modified: httpd/httpd/trunk/modules/cache/mod_socache_shmcb.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/mod_socache_shmcb.c?rev=1736243&r1=1736242&r2=1736243&view=diff
>
> ==
> --- httpd/httpd/trunk/modules/cache/mod_socache_shmcb.c (original)
> +++ httpd/httpd/trunk/modules/cache/mod_socache_shmcb.c Tue Mar 22
> 20:06:32 2016
> @@ -29,6 +29,10 @@
>  #include "apr_want.h"
>  #include "apr_general.h"
>
> +#if APR_HAVE_LIMITS_H
> +#include 
> +#endif
> +
>  #include "ap_socache.h"
>
>  /* XXX Unfortunately, there are still many unsigned ints in use here, so
> we
>
>
>

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Stefan Eissing]

Hmm, I thought we had that fixed by adding the proper compiler flags in 
maintainer mode. Will fix tomorrow morning. 

Stefan

> Am 22.03.2016 um 20:59 schrieb Eric Covener :
> 
>> On Tue, Mar 22, 2016 at 3:57 PM, William A Rowe Jr  
>> wrote:
>> Finally, just confirming we have decided that C99 is now the minimum
>> supported compiler feature set- used for the vardic macros in h2_filter.c?
> 
> I don't think that is meant to be bumped. We definitely had simpler
> c99-isms fixed in h2.
> 
> -- 
> Eric Covener
> cove...@gmail.com

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Jeff Trawick]

On Tue, Mar 22, 2016 at 3:55 PM, William A Rowe Jr 
wrote:

> Can anyone get mod_lbmethod_rr.c to build?
>

That's funny actually.  The very first version README.cmake in trunk says
that mod_lbmethod_rr.c doesn't build on Windows, yet the only build support
I can find for that module for any platform is in the legacy Windows build
system.  I guess the legacy build spews some error messages and continues
on with the next module?

Meanwhile the proverbial dog is actively chewing on my homework (can't get
past unresolved references in mod_http2 build -- nghttp2 symbols, not the
mod_http2 symbols discussed in this thread) so I'll forget I said anything
about trying to build mod_lbmethod_rr, as there is So Little Time.



> I'm seeing 'name' : is not a member of 'proxy_balancer' errors,
> as well as ap_proxy_retry_worker() undefined (converted into
> an optional function, perhaps?)
>
> On Mon, Mar 21, 2016 at 12:37 PM, Jim Jagielski  wrote:
>
>> The pre-release test tarballs for Apache httpd 2.4.19 can be found
>> at the usual place:
>>
>> http://httpd.apache.org/dev/dist/
>>
>> I'm calling a VOTE on releasing these as Apache httpd 2.4.19 GA.
>>
>> [ ] +1: Good to go
>> [ ] +0: meh
>> [ ] -1: Danger Will Robinson. And why.
>>
>> Vote will last the normal 72 hrs.
>>
>> NOTE: The *-deps are only there for convenience.
>>
>> Thx!
>>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[Yann Ylavic]

Done in r1736250 (and merged in r1736251).

On Tue, Mar 22, 2016 at 9:27 PM, Stefan Eissing
 wrote:
> Hmm, I thought we had that fixed by adding the proper compiler flags in 
> maintainer mode. Will fix tomorrow morning.
>
> Stefan
>
>> Am 22.03.2016 um 20:59 schrieb Eric Covener :
>>
>>> On Tue, Mar 22, 2016 at 3:57 PM, William A Rowe Jr  
>>> wrote:
>>> Finally, just confirming we have decided that C99 is now the minimum
>>> supported compiler feature set- used for the vardic macros in h2_filter.c?
>>
>> I don't think that is meant to be bumped. We definitely had simpler
>> c99-isms fixed in h2.
>>
>> --
>> Eric Covener
>> cove...@gmail.com

Re: svn commit: r1736243 - /httpd/httpd/trunk/modules/cache/mod_socache_shmcb.c

[Yann Ylavic]

On Tue, Mar 22, 2016 at 9:09 PM, William A Rowe Jr  wrote:
> Without objection, I'll be committing the backport in an hr or so for the
> morning T&R... this hardly seems to merit a vote, but any objections
> are welcome.

+1

Re: svn commit: r1736242 - /httpd/httpd/branches/2.4.x/modules/proxy/examples/mod_lbmethod_rr.dsp

[Yann Ylavic]

On Tue, Mar 22, 2016 at 9:00 PM,   wrote:
> Author: wrowe
> Date: Tue Mar 22 20:00:08 2016
> New Revision: 1736242
>
> URL: http://svn.apache.org/viewvc?rev=1736242&view=rev
> Log:
> Ensure we pick up modules/proxy/*.h headers
>
> Modified:
> httpd/httpd/branches/2.4.x/modules/proxy/examples/mod_lbmethod_rr.dsp

No need to fix in trunk?

Re: svn commit: r1736243 - /httpd/httpd/trunk/modules/cache/mod_socache_shmcb.c

[Stefan Eissing]

+1

> Am 22.03.2016 um 21:55 schrieb Yann Ylavic :
> 
>> On Tue, Mar 22, 2016 at 9:09 PM, William A Rowe Jr  
>> wrote:
>> Without objection, I'll be committing the backport in an hr or so for the
>> morning T&R... this hardly seems to merit a vote, but any objections
>> are welcome.
> 
> +1

Re: svn commit: r1736251 - in /httpd/httpd/branches/2.4.x: ./ modules/http2/h2_filter.c

[Stefan Eissing]

Thanks, Yann. 

> Am 22.03.2016 um 21:48 schrieb yla...@apache.org:
> 
> Author: ylavic
> Date: Tue Mar 22 20:48:47 2016
> New Revision: 1736251
> 
> URL: http://svn.apache.org/viewvc?rev=1736251&view=rev
> Log:
> Merge r1736250 from trunk:
> 
> mod_http2: no variadic macro in C89, use equivalent function.
> Reviewed/backported by: ylavic
> 
> Modified:
>httpd/httpd/branches/2.4.x/   (props changed)
>httpd/httpd/branches/2.4.x/modules/http2/h2_filter.c
> 
> Propchange: httpd/httpd/branches/2.4.x/
> --
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Tue Mar 22 20:48:47 2016
> @@ -2,4 +2,4 @@
> /httpd/httpd/branches/2.4.17-protocols-http2:1701609-1705681
> /httpd/httpd/branches/revert-ap-ldap:1150158-1150173
> /httpd/httpd/branches/wombat-integration:723609-723841
> -/httpd/httpd/trunk:1200475,1200478,1200482,1200491,1200496,1200513,1200550,1200556,1200580,1200605,1200612,1200614,1200639,1200646,1200656,1200667,1200679,1200699,1200702,1200955,1200957,1200961,1200963,1200968,1200975,1200977,1201032,1201042,120,1201194,1201198,1201202,1201443,1201450,1201460,1201956,1202236,1202453,1202456,1202886,1203400,1203491,1203632,1203714,1203859,1203980,1204630,1204968,1204990,1205061,1205075,1205379,1205885,1206291,1206472,1206587,1206850,1206940,1206978,1207719,1208753,1208835,1209053,1209085,1209417,1209432,1209461,1209601,1209603,1209618,1209623,1209741,1209754,1209766,1209776,1209797-1209798,1209811-1209812,1209814,1209908,1209910,1209913,1209916-1209917,1209947,1209952,1210067,1210080,1210120,1210124,1210130,1210148,1210219,1210221,1210252,1210284,1210336,1210378,1210725,1210892,1210951,1210954,1211351-1211352,1211364,1211490,1211495,1211528,1211663,1211680,1212872,1212883,1213338,1213380-1213381,1213391,1213399,1213567,1214003,1214005,1214015,12
> 15514,1220462,1220467,1220493,1220524,1220570,1220768,1220794,1220826,1220846,1221205,1221292,1222335,1222370,1222473,1222915,1222917,1222921,1222930,1223048,1225060,1225197-1225199,1225223,1225380,1225476,1225478,1225791,1225795-1225796,1226339,1226375,1227910,1228700,1228816,1229024,1229059,1229099,1229116,1229134,1229136,1229930,1230286,1231255,1231257,1231442,1231446,1231508,1231510,1231518,1232575,1232594,1232630,1232838,1234180,1234297,1234479,1234511,1234565,1234574,1234642-1234643,1234876,1234899,1235019,1236122,1236701,1237407,1238545,1238768,1239029-1239030,1239071,1239565,1240315,1240470,1240778,1241069,1241071,1242089,1242798,1242967,1243176,1243246,1243797,1243799,1244211,1245717,1290823,1290835,1291819-1291820,1291834,1291840,1292043,1293405,1293534-1293535,1293658,1293678,1293708,1294306,1294349,1294356,1294358,1294372,1294471,1297560,1299718,1299786,1300766,130,1301725,1302444,1302483,1302653,1302665,1302674,1303201,1303435,1303827,1304087,1304874-1304875,1305167
> ,1305586,1306350,1306409,1306426,1306841,1307790,1308327,1308459,1309536,1309567,1311468,1324760,1325218,1325227,1325250,1325265,1325275,1325632,1325724,1326980,1326984,1326991,1327689,1328325-1328326,1328339,1328345,1328950,1330189,1330964,1331110,1331115,1331942,1331977,1332378,1333969,1334343,1335882,1337344,1341906,1341913,1343085,1343087,1343094,1343099,1343109,1343935,1345319,1345329,1346905,1347980,1348036,1348653,1348656,1348660,1349905,1351012-1351020,1351071-1351072,1351074,1351737,1352047,1352534,1352909-1352912,1357685,1358061,1359057,1359881,1359884,1361153,1361298,1361766,1361773,1361778,1361784,1361791-1361792,1361801,1361803,1362020,1362538,1362707,1363035,1363183,1363186,1363312,1363440,1363557,1363589,1363829,1363832,1363836-1363837,1363853,1364133,1364138,1364229,1364601,1364695,1365001,1365020,1365029,1365479,1366319,1366344,1366621,1367778,1367819,1368053,1368058,1368094,1368121,1368131,1368393,1368396,1369419,1369568,1369604,1369618,1369904,1369995,136,1370
> 001,1370466,1370592,1370615-1370616,1370763,1371387,1371791,1371801,1371878,1371903,1373270,1373447,1373898,1373955,1374157,1374199,1374247,1374874,1374877,1374880,1375006,1375009,1375011,1375013,1375584,1376695,1376700,1378178,1383490,1384408,1384913,1386576,1386578,1386726,1386822,1386880,1386913,1387085,1387088,1387110,1387389,1387444,1387603,1387607,1387633,1387693,1387979,1388029,1388445,1388447,1388648,1388660,1388825,1388899,1389316,1389339,1389481,1389506,1389564,1389566-1389569,1390562,1390564,1391396,1391398,1391771,1392120,1392122,1392150,1392214,1392345-1392347,1392850,1393033,1393058,1393152,1393338,1393564,1394079,1395225,1395253-1395256,1395792,1397172,1397320,1397636,1397687,1397710,1397716,1398025,1398040,1398066,1398478,1398480-1398481,1398970,1399413,1399687,1399708,1400700,1401448,1402924,1403476,1403483,1403492,1404653,1405407,1405856,1405973,1406068,1406493,1406495,1406616,1406646,1406760,1407004,1407006,1407085,1407088,1407248,1407381,1407459-1407460,1407528,1
> 407853,1407965,1408093,1408402,1408958,1408961,1409170,1409437,1409726,1409800,1410681,1410954,1411862,1412278,1413732,1414094,1415008,1

fate of mod_lbmethod_rr (was: Re: [VOTE] Release Apache httpd 2.4.19 as GA)

[William A Rowe Jr]

On Tue, Mar 22, 2016 at 3:38 PM, Jeff Trawick  wrote:

> On Tue, Mar 22, 2016 at 3:55 PM, William A Rowe Jr 
> wrote:
>
>> Can anyone get mod_lbmethod_rr.c to build?
>>
>
> That's funny actually.  The very first version README.cmake in trunk says
> that mod_lbmethod_rr.c doesn't build on Windows
>

 When I added the .dsp, it certainly did build.  --enable-mods=all should
be
triggering the build of those sources.

I think this illustrates that we have played fast and loose with something
that
1. is a public API, 2. not experimental, and 3. was illustrated with an
example
that has been frequently broken by Major ABI changes.

If devs want to promote an API and then continuously break ABI on trunk,
I'm way beyond arguing with such individuals.  Just a few choice examples
which had necessitated major MMN bumps that did not receive one...

http://svn.apache.org/viewvc?view=revision&revision=1560081
http://svn.apache.org/viewvc?view=revision&revision=1477649 (no
bitwise-alignment assurance)
http://svn.apache.org/viewvc?view=revision&revision=1436919 (no
bitwise-alignment assurance)

However, this module appears to have been broken prior to 2.4.1 GA with this
at least this commit...
http://svn.apache.org/viewvc?view=revision&revision=1209958
... which tells me it is simply an abandoned example.

I propose we remove it from 2.4.x branch and trunk, rather than pretending
we have maintained it?

Re: svn commit: r1736242 - /httpd/httpd/branches/2.4.x/modules/proxy/examples/mod_lbmethod_rr.dsp

[William A Rowe Jr]

I think the argument will quickly become moot... see other thread.

I also don't expect we will persist .dsp on trunk for very much longer,
/shrug

On Tue, Mar 22, 2016 at 3:56 PM, Yann Ylavic  wrote:

> On Tue, Mar 22, 2016 at 9:00 PM,   wrote:
> > Author: wrowe
> > Date: Tue Mar 22 20:00:08 2016
> > New Revision: 1736242
> >
> > URL: http://svn.apache.org/viewvc?rev=1736242&view=rev
> > Log:
> > Ensure we pick up modules/proxy/*.h headers
> >
> > Modified:
> > httpd/httpd/branches/2.4.x/modules/proxy/examples/mod_lbmethod_rr.dsp
>
> No need to fix in trunk?
>

Re: [VOTE] Release Apache httpd 2.4.19 as GA

[William A Rowe Jr]

On Tue, Mar 22, 2016 at 3:38 PM, Jeff Trawick  wrote:

> On Tue, Mar 22, 2016 at 3:55 PM, William A Rowe Jr 
> wrote:
>
>> Can anyone get mod_lbmethod_rr.c to build?
>>
>
> That's funny actually.  The very first version README.cmake in trunk says
> that mod_lbmethod_rr.c doesn't build on Windows, yet the only build support
> I can find for that module for any platform is in the legacy Windows build
> system.  I guess the legacy build spews some error messages and continues
> on with the next module?
>

Actually, no.  The legacy "BuildAll" target is almost never a target, think
of it as
the Windows equivalent of --enable-modules=really-all :)  It is the method
to
spit out mod_bucketeer and other example/experimental/test modules.

The only reason I built it was to extract .mak & .dep files, which is how
I'd
tripped over something that has apparently been broken for some 4 years.

Re: fate of mod_lbmethod_rr (was: Re: [VOTE] Release Apache httpd 2.4.19 as GA)

[Jeff Trawick]

On Tue, Mar 22, 2016 at 5:03 PM, William A Rowe Jr 
wrote:

> On Tue, Mar 22, 2016 at 3:38 PM, Jeff Trawick  wrote:
>
>> On Tue, Mar 22, 2016 at 3:55 PM, William A Rowe Jr 
>> wrote:
>>
>>> Can anyone get mod_lbmethod_rr.c to build?
>>>
>>
>> That's funny actually.  The very first version README.cmake in trunk says
>> that mod_lbmethod_rr.c doesn't build on Windows
>>
>
>  When I added the .dsp, it certainly did build.  --enable-mods=all should
> be
> triggering the build of those sources.
>
> I think this illustrates that we have played fast and loose with something
> that
> 1. is a public API, 2. not experimental, and 3. was illustrated with an
> example
> that has been frequently broken by Major ABI changes.
>
> If devs want to promote an API and then continuously break ABI on trunk,
> I'm way beyond arguing with such individuals.  Just a few choice examples
> which had necessitated major MMN bumps that did not receive one...
>
> http://svn.apache.org/viewvc?view=revision&revision=1560081
> http://svn.apache.org/viewvc?view=revision&revision=1477649 (no
> bitwise-alignment assurance)
> http://svn.apache.org/viewvc?view=revision&revision=1436919 (no
> bitwise-alignment assurance)
>
> However, this module appears to have been broken prior to 2.4.1 GA with
> this
> at least this commit...
> http://svn.apache.org/viewvc?view=revision&revision=1209958
> ... which tells me it is simply an abandoned example.
>
> I propose we remove it from 2.4.x branch and trunk, rather than pretending
> we have maintained it?
>

+1 for removing from 2.4.x branch

no arguments here if someone actually wants it to hang around in trunk, but
I don't actually know if anybody cares so no vote on trunk ATM...

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

About the relevance of bitfields usage (was: fate of mod_lbmethod_rr...)

[Yann Ylavic]

... if we cannot extend them.

On Tue, Mar 22, 2016 at 10:03 PM, William A Rowe Jr  wrote:
>
> If devs want to promote an API and then continuously break ABI on trunk,
> I'm way beyond arguing with such individuals.  Just a few choice examples
> which had necessitated major MMN bumps that did not receive one...
>
> http://svn.apache.org/viewvc?view=revision&revision=1560081
> http://svn.apache.org/viewvc?view=revision&revision=1477649 (no
> bitwise-alignment assurance)
> http://svn.apache.org/viewvc?view=revision&revision=1436919 (no
> bitwise-alignment assurance)

These for sure broke users depending on bit alignement of the
bitfield(s), but isn't that really an abuse of the/any API?

Anyway, if we can't extend bitfields, we'd better not use them, and
favor plain (unsigned) integer types with #defined (or enum) bits
positions like:

#define req_set (APR_UINT64_C(1) <<  0)
#define viaopt_set  (APR_UINT64_C(1) <<  1)
#define recv_buffer_size_set(APR_UINT64_C(1) <<  2)
#define io_buffer_size_set  (APR_UINT64_C(1) <<  3)
#define maxfwd_set  (APR_UINT64_C(1) <<  4)
#define timeout_set (APR_UINT64_C(1) <<  5)
#define badopt_set  (APR_UINT64_C(1) <<  6)
#define proxy_status_set(APR_UINT64_C(1) <<  7)
#define source_address_set  (APR_UINT64_C(1) <<  8)
#define bgrowth_set (APR_UINT64_C(1) <<  9)
#define bal_persist (APR_UINT64_C(1) << 10)
#define inherit (APR_UINT64_C(1) << 11)
#define inherit_set (APR_UINT64_C(1) << 12)
#define ppinherit   (APR_UINT64_C(1) << 13)
#define ppinherit_set   (APR_UINT64_C(1) << 14)

struct {

apr_uint64_t flags;
} proxy_server_conf;

We can then use them with (e.g.):

if (sconf->flags & ppinherit_set) {

}

That (at least) won't cause any breakage if we add a new flag or a
following (trailing) flags2.

My 2 cts...

Re: About the relevance of bitfields usage (was: fate of mod_lbmethod_rr...)

[William A Rowe Jr]

I still can't find anything in the spec that suggests that extending these
is assured to maintain bitwise alignment.

That said, we can, provided we add an aligned break between them.  That
might mean introducing an interview flag, followed by a new series of
bitwise flags between, for example, the 2.4.20 and 2.4.21 releases.

Common sense tells me that alignment should be preserved, but unless we can
trust the spec to ensure that assumption, we should err on the side of
caution.
On Mar 22, 2016 4:46 PM, "Yann Ylavic"  wrote:

> ... if we cannot extend them.
>
> On Tue, Mar 22, 2016 at 10:03 PM, William A Rowe Jr 
> wrote:
> >
> > If devs want to promote an API and then continuously break ABI on trunk,
> > I'm way beyond arguing with such individuals.  Just a few choice examples
> > which had necessitated major MMN bumps that did not receive one...
> >
> > http://svn.apache.org/viewvc?view=revision&revision=1560081
> > http://svn.apache.org/viewvc?view=revision&revision=1477649 (no
> > bitwise-alignment assurance)
> > http://svn.apache.org/viewvc?view=revision&revision=1436919 (no
> > bitwise-alignment assurance)
>
> These for sure broke users depending on bit alignement of the
> bitfield(s), but isn't that really an abuse of the/any API?
>
> Anyway, if we can't extend bitfields, we'd better not use them, and
> favor plain (unsigned) integer types with #defined (or enum) bits
> positions like:
>
> #define req_set (APR_UINT64_C(1) <<  0)
> #define viaopt_set  (APR_UINT64_C(1) <<  1)
> #define recv_buffer_size_set(APR_UINT64_C(1) <<  2)
> #define io_buffer_size_set  (APR_UINT64_C(1) <<  3)
> #define maxfwd_set  (APR_UINT64_C(1) <<  4)
> #define timeout_set (APR_UINT64_C(1) <<  5)
> #define badopt_set  (APR_UINT64_C(1) <<  6)
> #define proxy_status_set(APR_UINT64_C(1) <<  7)
> #define source_address_set  (APR_UINT64_C(1) <<  8)
> #define bgrowth_set (APR_UINT64_C(1) <<  9)
> #define bal_persist (APR_UINT64_C(1) << 10)
> #define inherit (APR_UINT64_C(1) << 11)
> #define inherit_set (APR_UINT64_C(1) << 12)
> #define ppinherit   (APR_UINT64_C(1) << 13)
> #define ppinherit_set   (APR_UINT64_C(1) << 14)
>
> struct {
> 
> apr_uint64_t flags;
> } proxy_server_conf;
>
> We can then use them with (e.g.):
>
> if (sconf->flags & ppinherit_set) {
> 
> }
>
> That (at least) won't cause any breakage if we add a new flag or a
> following (trailing) flags2.
>
> My 2 cts...
>

Re: About the relevance of bitfields usage (was: fate of mod_lbmethod_rr...)

[Yann Ylavic]

On Tue, Mar 22, 2016 at 10:50 PM, William A Rowe Jr  wrote:
> I still can't find anything in the spec that suggests that extending these
> is assured to maintain bitwise alignment.

Indeed there is none, that's why users should not depend on it, IMHO.

>
> That said, we can, provided we add an aligned break between them.  That
> might mean introducing an interview flag, followed by a new series of
> bitwise flags between, for example, the 2.4.20 and 2.4.21 releases.

That means losing space IIUC, which pretty much avoids bitfields interest.

>
> Common sense tells me that alignment should be preserved, but unless we can
> trust the spec to ensure that assumption, we should err on the side of
> caution.

So let's not use bitfields, there are other ways to do it, and macros
could help for bit(s) definition/checking/handling...

Need hints from those building mod_http2 and mod_proxy_http2 on Windows

[Jeff Trawick]

What version of nghttp2 are you using?
Are you using the cmake build for httpd?


FWIW I just found that I needed nghttp2 >= 1.4.0 on Windows to fix bad
linkage in nghttp2 functions that mod_http2 didn't use when I built before.
 (not related to cmake)

After resolving that I now see a bunch of unresolved symbols with
mod_proxy_http2.  From the number of symbols and the type there seems to be
a couple of issues in the httpd CMakeLists.txt file.  I can hopefully look
at that early tomorrow a.m.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Need hints from those building mod_http2 and mod_proxy_http2 on Windows

[Jacob Champion]

On 03/22/2016 03:11 PM, Jeff Trawick wrote:
> What version of nghttp2 are you using?
> Are you using the cmake build for httpd?

I'm not currently in Windows to be able to check for sure, but I
*believe* I'm running nghttp2 1.8.0.

> FWIW I just found that I needed nghttp2 >= 1.4.0 on Windows to fix bad
> linkage in nghttp2 functions that mod_http2 didn't use when I built
> before.  (not related to cmake)
> 
> After resolving that I now see a bunch of unresolved symbols with
> mod_proxy_http2.  From the number of symbols and the type there seems to
> be a couple of issues in the httpd CMakeLists.txt file.  I can hopefully
> look at that early tomorrow a.m.

The CMake/mod_proxy_http2 stuff came up before [1]. I didn't hear back
from Bill on how his CMake port was going, but I ended up working on one
in parallel:

https://github.com/jchampio/httpd/commits/dev/cmake-http2

Caveat: I haven't taken a look at that patchset in three weeks, or tried
to rebase onto latest. I hope it's still potentially useful for you?

--Jacob

[1]
http://mail-archives.apache.org/mod_mbox//httpd-dev/201602.mbox/%3CCAGu%3Du8gSex0%2B4KXfmy_rYCdcB-_TOfb-aZ1%3DrhBihYePx%3D8Tug%40mail.gmail.com%3E

Re: TLS session ticket key (shared) renewal

[Yann Ylavic]

On Tue, Mar 22, 2016 at 4:18 PM, Paul Querna  wrote:
> My thought was to add support for either multiple files, or multiple values
> in the existing `SSLSessionTicketKeyFile`.  Then add support to decrypt from
> any of the known keys, and have a setting (or the first loaded key) would be
> used to encrypt all new keys.  This would allow for rotation in a reasonable
> manner.

That's indeed a great improvement on what we have now, and actually
looks like you first introduced it in r1200040 :)
Why was it not kept that way?

We'll still need a (graceful) restart to renew the keys, though.

Also, it seems there is interest in sharing the keys accross different
instances/machines, is a file (unless on something like an NFS mount)
an option here?

Re: Need hints from those building mod_http2 and mod_proxy_http2 on Windows

[Jeff Trawick]

On Tue, Mar 22, 2016 at 6:31 PM, Jacob Champion 
wrote:

> On 03/22/2016 03:11 PM, Jeff Trawick wrote:
> > What version of nghttp2 are you using?
> > Are you using the cmake build for httpd?
>
> I'm not currently in Windows to be able to check for sure, but I
> *believe* I'm running nghttp2 1.8.0.
>
> > FWIW I just found that I needed nghttp2 >= 1.4.0 on Windows to fix bad
> > linkage in nghttp2 functions that mod_http2 didn't use when I built
> > before.  (not related to cmake)
> >
> > After resolving that I now see a bunch of unresolved symbols with
> > mod_proxy_http2.  From the number of symbols and the type there seems to
> > be a couple of issues in the httpd CMakeLists.txt file.  I can hopefully
> > look at that early tomorrow a.m.
>
> The CMake/mod_proxy_http2 stuff came up before [1]. I didn't hear back
> from Bill on how his CMake port was going, but I ended up working on one
> in parallel:
>
> https://github.com/jchampio/httpd/commits/dev/cmake-http2
>
> Caveat: I haven't taken a look at that patchset in three weeks, or tried
> to rebase onto latest. I hope it's still potentially useful for you?
>
> --Jacob
>
> [1]
>
> http://mail-archives.apache.org/mod_mbox//httpd-dev/201602.mbox/%3CCAGu%3Du8gSex0%2B4KXfmy_rYCdcB-_TOfb-aZ1%3DrhBihYePx%3D8Tug%40mail.gmail.com%3E


Yes, that's useful.  In the short term it makes it easy to tell that
mod_proxy_http2 simply does not build/run on Windows at all and needs to be
yanked out of the CMake build for 2.4.x until it does, since it breaks the
build.

I hope that I or someone else has time to work through your fixes before
long.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Need hints from those building mod_http2 and mod_proxy_http2 on Windows

[Jeff Trawick]

On Tue, Mar 22, 2016 at 6:37 PM, Jeff Trawick  wrote:

> On Tue, Mar 22, 2016 at 6:31 PM, Jacob Champion 
> wrote:
>
>> On 03/22/2016 03:11 PM, Jeff Trawick wrote:
>> > What version of nghttp2 are you using?
>> > Are you using the cmake build for httpd?
>>
>> I'm not currently in Windows to be able to check for sure, but I
>> *believe* I'm running nghttp2 1.8.0.
>>
>> > FWIW I just found that I needed nghttp2 >= 1.4.0 on Windows to fix bad
>> > linkage in nghttp2 functions that mod_http2 didn't use when I built
>> > before.  (not related to cmake)
>> >
>> > After resolving that I now see a bunch of unresolved symbols with
>> > mod_proxy_http2.  From the number of symbols and the type there seems to
>> > be a couple of issues in the httpd CMakeLists.txt file.  I can hopefully
>> > look at that early tomorrow a.m.
>>
>> The CMake/mod_proxy_http2 stuff came up before [1]. I didn't hear back
>> from Bill on how his CMake port was going, but I ended up working on one
>> in parallel:
>>
>> https://github.com/jchampio/httpd/commits/dev/cmake-http2
>>
>> Caveat: I haven't taken a look at that patchset in three weeks, or tried
>> to rebase onto latest. I hope it's still potentially useful for you?
>>
>> --Jacob
>>
>> [1]
>>
>> http://mail-archives.apache.org/mod_mbox//httpd-dev/201602.mbox/%3CCAGu%3Du8gSex0%2B4KXfmy_rYCdcB-_TOfb-aZ1%3DrhBihYePx%3D8Tug%40mail.gmail.com%3E
>
>
> Yes, that's useful.  In the short term it makes it easy to tell that
> mod_proxy_http2 simply does not build/run on Windows at all and needs to be
> yanked out of the CMake build for 2.4.x until it does, since it breaks the
> build.
>

I can't stop being an idiot, I'm afraid.  It is in the trunk build, not
2.4.x; let me switch source trees again :)


>
> I hope that I or someone else has time to work through your fixes before
> long.
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: About the relevance of bitfields usage (was: fate of mod_lbmethod_rr...)

[William A Rowe Jr]

On Tue, Mar 22, 2016 at 5:08 PM, Yann Ylavic  wrote:

>
> > Common sense tells me that alignment should be preserved, but unless we
> can
> > trust the spec to ensure that assumption, we should err on the side of
> > caution.
>
> So let's not use bitfields, there are other ways to do it, and macros
> could help for bit(s) definition/checking/handling...
>

Let's continue to use them as we prepare for 2.6.0 - where we have the
opportunity to drop ABI and pack all of our bit flags in one place, that
still makes a lot of sense.  So would adding a group of bitfields, as was
the case in one of the commits I noted.  An int (for alignment) and three
int-bitflags still saves us two ints in the structure.

Re: Need hints from those building mod_http2 and mod_proxy_http2 on Windows

[Jan Ehrhardt]

Jeff Trawick in gmane.comp.apache.devel (Tue, 22 Mar 2016 18:11:59 -0400):
>What version of nghttp2 are you using?

I always use git head of nghttp2. So that is > v1.8.0 ATM

>Are you using the cmake build for httpd?

No. I open the *.dsw / *.dsp in with VC9 / VC11, after applying these
operations:

 cd C:\build\2.4.x 
 srclib\apr\build\lineends.pl 
 srclib\apr\build\cvtdsp.pl -2005

See https://www.apachelounge.com/viewtopic.php?p=33069#33069
That is the way Apachelounge & Apachehaus build httpd.
FYI: James Blond == Mario Brandt

Jan

Re: TLS session ticket key (shared) renewal

[Paul Querna]

On Tue, Mar 22, 2016 at 3:32 PM, Yann Ylavic  wrote:

> On Tue, Mar 22, 2016 at 4:18 PM, Paul Querna  wrote:
> > My thought was to add support for either multiple files, or multiple
> values
> > in the existing `SSLSessionTicketKeyFile`.  Then add support to decrypt
> from
> > any of the known keys, and have a setting (or the first loaded key)
> would be
> > used to encrypt all new keys.  This would allow for rotation in a
> reasonable
> > manner.
>
> That's indeed a great improvement on what we have now, and actually
> looks like you first introduced it in r1200040 :)
> Why was it not kept that way?
>
> We'll still need a (graceful) restart to renew the keys, though.
>

(unix mpms) Having the a process (mpm_register_timed_callback? other
hooks?) re-read
the file periodically or on change, and set them set it in a slot mem is
reasonable, but not the behavior of almost any other file reference in
httpd... so the pattern of graceful is how most things work, I can't figure
out why session tickets are worth an exception to this pattern?


> Also, it seems there is interest in sharing the keys accross different
> instances/machines, is a file (unless on something like an NFS mount)
> an option here?
>

Most large scale deployments have configuration management or other
techniques to synchronize secret values across many machines;  I don't
think we should go overboard in building a network transport for session
ticket secrets.

Re: TLS session ticket key (shared) renewal

[Rainer Jung]

Am 23.03.2016 um 00:30 schrieb Paul Querna:



On Tue, Mar 22, 2016 at 3:32 PM, Yann Ylavic mailto:ylavic@gmail.com>> wrote:

On Tue, Mar 22, 2016 at 4:18 PM, Paul Querna mailto:p...@querna.org>> wrote:
> My thought was to add support for either multiple files, or multiple 
values
> in the existing `SSLSessionTicketKeyFile`.  Then add support to decrypt 
from
> any of the known keys, and have a setting (or the first loaded key) would 
be
> used to encrypt all new keys.  This would allow for rotation in a 
reasonable
> manner.

That's indeed a great improvement on what we have now, and actually
looks like you first introduced it in r1200040 :)
Why was it not kept that way?

We'll still need a (graceful) restart to renew the keys, though.


(unix mpms) Having the a process (mpm_register_timed_callback? other
hooks?) re-read the file periodically or on change, and set them set it
in a slot mem is reasonable, but not the behavior of almost any other
file reference in httpd... so the pattern of graceful is how most things
work, I can't figure out why session tickets are worth an exception to
this pattern?

Also, it seems there is interest in sharing the keys accross different
instances/machines, is a file (unless on something like an NFS mount)
an option here?


Most large scale deployments have configuration management or other
techniques to synchronize secret values across many machines;  I don't
think we should go overboard in building a network transport for session
ticket secrets.


Yann had the interesting idea to use a key derivation scheme like PBKDF2 
to create a sequence of keys, key renewal triggered e.g. as suggested by 
Rüdiger time-based. Such a scheme would only need to distribute the 
initial key file between farm nodes, but not an update to the file e.g. 
once a day. I like that idea, although I can't really judge on the 
safeness of the derived keys. Such a key derivation scheme (there are 
also others, Wikipedia refers to Argon2) seems not to be exotic.


Regards,

Rainer

Re: Need hints from those building mod_http2 and mod_proxy_http2 on Windows

[William A Rowe Jr]

I've had success with Jeff's minimalist nghttp build schema.  A larger
effort at a cmake for the full stack (lib+apps) has been in the works for a
month or two now, haven't had a chance to try it.
On Mar 22, 2016 6:27 PM, "Jan Ehrhardt"  wrote:

> Jeff Trawick in gmane.comp.apache.devel (Tue, 22 Mar 2016 18:11:59 -0400):
> >What version of nghttp2 are you using?
>
> I always use git head of nghttp2. So that is > v1.8.0 ATM
>
> >Are you using the cmake build for httpd?
>
> No. I open the *.dsw / *.dsp in with VC9 / VC11, after applying these
> operations:
>
>  cd C:\build\2.4.x
>  srclib\apr\build\lineends.pl
>  srclib\apr\build\cvtdsp.pl -2005
>
> See https://www.apachelounge.com/viewtopic.php?p=33069#33069
> That is the way Apachelounge & Apachehaus build httpd.
> FYI: James Blond == Mario Brandt
>
> Jan
>
>

Re: svn commit: r1736216 - in /httpd/httpd/trunk: include/httpd.h modules/http/http_request.c server/mpm/event/event.c server/mpm/motorz/motorz.c server/mpm/simple/simple_io.c server/util_filter.c

[Graham Leggett]

On 22 Mar 2016, at 7:08 PM, yla...@apache.org wrote:

> URL: http://svn.apache.org/viewvc?rev=1736216&view=rev
> Log:
> Follow up to r1734656: restore c->data_in_input_filters usage to
> see if it helps unblocking test framework.

I created an almost identical patch before doing an update, the only difference 
was this:

Index: modules/http/http_request.c
===
--- modules/http/http_request.c (revision 1736263)
+++ modules/http/http_request.c (working copy)
@@ -453,7 +453,7 @@
 
 ap_process_async_request(r);
 
-if (!c->data_in_input_filters || ap_run_input_pending(c) != OK) {
+if (!c->data_in_input_filters && ap_run_input_pending(c) != OK) {
 bb = apr_brigade_create(c->pool, c->bucket_alloc);
 b = apr_bucket_flush_create(c->bucket_alloc);
 APR_BRIGADE_INSERT_HEAD(bb, b);

I get hangs without the above patch on the test suite, but it runs clean with. 
Can you give it a try?

Regards,
Graham
—

Re: fate of mod_lbmethod_rr (was: Re: [VOTE] Release Apache httpd 2.4.19 as GA)

[William A Rowe Jr]

On Tue, Mar 22, 2016 at 4:15 PM, Jeff Trawick  wrote:

> On Tue, Mar 22, 2016 at 5:03 PM, William A Rowe Jr 
> wrote:
>
>> On Tue, Mar 22, 2016 at 3:38 PM, Jeff Trawick  wrote:
>>
>>> On Tue, Mar 22, 2016 at 3:55 PM, William A Rowe Jr 
>>> wrote:
>>>
 Can anyone get mod_lbmethod_rr.c to build?

>>>
>>> That's funny actually.  The very first version README.cmake in trunk
>>> says that mod_lbmethod_rr.c doesn't build on Windows
>>>
>>
>>  When I added the .dsp, it certainly did build.  --enable-mods=all should
>> be
>> triggering the build of those sources.
>>
>> I think this illustrates that we have played fast and loose with
>> something that
>> 1. is a public API, 2. not experimental, and 3. was illustrated with an
>> example
>> that has been frequently broken by Major ABI changes.
>>
>> If devs want to promote an API and then continuously break ABI on trunk,
>> I'm way beyond arguing with such individuals.  Just a few choice examples
>> which had necessitated major MMN bumps that did not receive one...
>>
>> http://svn.apache.org/viewvc?view=revision&revision=1560081
>> http://svn.apache.org/viewvc?view=revision&revision=1477649 (no
>> bitwise-alignment assurance)
>> http://svn.apache.org/viewvc?view=revision&revision=1436919 (no
>> bitwise-alignment assurance)
>>
>> However, this module appears to have been broken prior to 2.4.1 GA with
>> this
>> at least this commit...
>> http://svn.apache.org/viewvc?view=revision&revision=1209958
>> ... which tells me it is simply an abandoned example.
>>
>> I propose we remove it from 2.4.x branch and trunk, rather than
>> pretending
>> we have maintained it?
>>
>
> +1 for removing from 2.4.x branch
>
> no arguments here if someone actually wants it to hang around in trunk,
> but I don't actually know if anybody cares so no vote on trunk ATM...
>

I agree, this discussion is only about 2.4.x branch for the imminent T&R.

If I have a third +1 for removing this horridly wrong example/, I'll commit
in the next 2 hours.  If there is disagreement later, we can always revert.

Bill