date:20160617

Re: [VOTE] Release Apache httpd 2.4.21 as GA

2016-06-17 Thread Jacob Champion

> [x] +1: Good to go

Built:

Ubuntu 14.04 (x64): apr-2, openssl-1.0.2d, nghttp2-1.8.0
Ubuntu 16.04 (x64): apr-1.5.2, apu-1.5.4, openssl-1.0.2g,
nghttp2-1.10.0
Windows 7  (x64, MSVC14): apr-2, openssl-1.0.2g, nghttp2-1.8.0
Windows 10 (x64, MSVC14): apr-2, openssl-1.0.2h, nghttp2-1.10.0

Tested:

Ubuntu: Apache::Test, mod_websocket, DUMP_INCLUDES
Windows 7:  mod_websocket
Windows 10: mod_websocket, DUMP_INCLUDES, mod_proxy_http2
(w/ ProxyPass[Reverse])

--Jacob

Re: [VOTE] Release Apache httpd 2.4.21 as GA

2016-06-17 Thread Jan Ehrhardt

Jim Jagielski in gmane.comp.apache.devel (Thu, 16 Jun 2016 13:07:51
-0400):
>The pre-release test tarballs for Apache httpd 2.4.21 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.21 GA.
>
>[ ] +1: Good to go

Built on Windows with VC9, VC11, VC14 * x86, x64.

Tested on a Windows 2008R2 server, using
VC9,  x86
VC11, x64
VC14, x86

All with OpenSSl 1.0.2h Fips and mod_http2.
-- 
Jan

Re: [VOTE] Release Apache httpd 2.4.21 as GA

2016-06-17 Thread Jacob Perkins

[+] +1: Good to go

Tested on:
CentOS 6 (i686 & x86_64)
CentOS 7 (x86_64)

—
Jacob Perkins
Product Owner
cPanel Inc.

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

> On Jun 16, 2016, at 3:58 PM, olli hauer  wrote:
> 
>> The pre-release test tarballs for Apache httpd 2.4.21 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.21 GA.
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Hung 2.2.x STATUS entries...

2016-06-17 Thread Ruediger Pluem

On 06/17/2016 05:55 PM, William A Rowe Jr wrote:
> A couple of branches/2.2.x STATUS questions are outstanding...
> 
>   *) mod_mem_cache: Don't cache incomplete responses when the client aborts 
> the connection.
>  Not applicable to trunk, mod_mem_cache doesn't exist there.
>  2.2.x patch: http://people.apache.org/~elu/mem_cache_client_abort.diff
>  +1: elu,
>  ylavic: don't we know from the very beginning of store_body() if
>  r->connection->aborted, so to fail there?
>  rpluem: Agreed. I guess we can move this up to line 733 before the loop.
>  ylavic: Or even at the beginning if we want to avoid file caching too.
>  But finally I wonder why we would not cache the response provided
>  it is complete. Shouldn't incomplete response be detected with
>  error buckets instead? ISTM that EOS with no error bucket *is*
>  a complete response that could be cached even if the current
>  client won't receive it completely.
>  wrowe asks: Refreshed patch yet?  Will give this a week before moving to
>  the 'stalled' section below.
> 
> What's the resolution here? Is there a patch yet that satisfies you both,
> that we can review?

No that I am aware. Without having a patch at hand and time to create one 
currently I
guess the correct condition would be to NOT cache if the connection is aborted 
and there
is NO EOS bucket in the actual brigade. How to do this most effectively is left 
as an exercise
for the reader :-).
But I guess the best approach is to test before the brigade iteration whether 
the connection
is aborted and if it is if the brigade contains an EOS.

Maybe Yann's patches somehow got lost in the the people to home transfer.

Regards

Rüdiger

Re: Small problem in "configure" script with 2.4.21

2016-06-17 Thread Ruediger Pluem



On 06/17/2016 04:52 PM, Jens Schleusener wrote:
> On Fri, 17 Jun 2016, Ruediger Pluem wrote:
> 
>> I guess the following should fix this:
>>
>> Index: modules/proxy/config.m4
>> ===
>> --- modules/proxy/config.m4 (revision 1748670)
>> +++ modules/proxy/config.m4 (working copy)
>> @@ -13,6 +13,9 @@
>> if test "$proxy_mods_enable" = "no"; then
>>   enable_proxy_hcheck=no
>> fi
>> +if test -z "$enable_proxy_hcheck" ; then
>> +  enable_proxy_hcheck="$proxy_mods_enable"
>> +fi
>>
>> proxy_objs="mod_proxy.lo proxy_util.lo"
>> APACHE_MODULE(proxy, Apache proxy module, $proxy_objs, , $proxy_mods_enable)
>>
>>
>>
>> Of course you need to run buildconf before your next configure call to 
>> regenerate configure which
>> requires you to have Python, autoconf and libtool installed in suitable 
>> versions.
>>
>> Regards
>>
>> Rüdiger
> 
> Thanks Rüdiger, that works for me.

Thanks for testing. Committed to trunk as r174.

Regards

Rüdiger

Re: [VOTE] Release Apache httpd 2.4.21 as GA

2016-06-17 Thread Jim Jagielski


> On Jun 16, 2016, at 1:07 PM, Jim Jagielski  wrote:
> 
> The pre-release test tarballs for Apache httpd 2.4.21 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.21 GA.
> 
> [X] +1: Good to go

Tested:
  o CentOS6, x64
  o CentOS7, x64
  o OSX 10.11.5 / Xcode 7.3.1, x64

Re: TestSuite Docs (was Re: [VOTE] Release Apache httpd 2.4.21 as GA)

2016-06-17 Thread Jacob Champion


On 06/17/2016 08:25 AM, Jacob Perkins wrote:

I’d love to be able to quickly spin up a new RPM on our Apache & PHP
distribution and let automated tests slam it. Right now it’s sort of a
manual process.  A lot of what I’ve seen as far as a ‘how-to’ on setting
up Apache Test is something like ‘cpan -i Apache::Test’, but I haven’t
had great luck getting that working 100%.


As far as how to *install* the test suite, once you've checked out the 
SVN repo, the README helped me:


http://svn.apache.org/repos/asf/httpd/test/framework/trunk/README

It explains the recommended server configuration about halfway down.

https://perl.apache.org/docs/general/testing/testing.html is where I've 
found the most in-depth information on how to actually *run* the test 
suite (as well as instructions on how to develop the tests themselves).


It would be nice (TM) to have those consolidated into a single place. 
(Even nicer to have the tests integrated into the httpd repo!)


--Jacob

Hung 2.2.x STATUS entries...

2016-06-17 Thread William A Rowe Jr

A couple of branches/2.2.x STATUS questions are outstanding...

  *) mod_mem_cache: Don't cache incomplete responses when the client aborts
the connection.
 Not applicable to trunk, mod_mem_cache doesn't exist there.
 2.2.x patch: http://people.apache.org/~elu/mem_cache_client_abort.diff
 +1: elu,
 ylavic: don't we know from the very beginning of store_body() if
 r->connection->aborted, so to fail there?
 rpluem: Agreed. I guess we can move this up to line 733 before the
loop.
 ylavic: Or even at the beginning if we want to avoid file caching too.
 But finally I wonder why we would not cache the response
provided
 it is complete. Shouldn't incomplete response be detected with
 error buckets instead? ISTM that EOS with no error bucket *is*
 a complete response that could be cached even if the current
 client won't receive it completely.
 wrowe asks: Refreshed patch yet?  Will give this a week before moving
to
 the 'stalled' section below.

What's the resolution here? Is there a patch yet that satisfies you both,
that we can review?

And the following two patches are MIA, if you can refresh STATUS or
dig out the old patches, Yann...

  *) mod_substitute: Configure patterns merge order. PR 57641
 trunk patch: http://svn.apache.org/r1684900
  http://svn.apache.org/r1687539
  http://svn.apache.org/r1687680
  http://svn.apache.org/r1688331
  http://svn.apache.org/r1688339
  http://svn.apache.org/r1688340
  http://svn.apache.org/r1688343
  http://svn.apache.org/r1697013
  http://svn.apache.org/r1697015
 2.2.x patch:
http://people.apache.org/~ylavic/httpd-2.2.x-SubstituteInheritBefore-v5.patch
 +1: ylavic, rpluem
 rpluem: Doesn't that change the previous behaviour if
SubstituteInheritBefore is not set?
 ylavic: yes thanks, updated to v5 including r1697013 and r1697015,
 the diff to v4 is:

http://people.apache.org/~ylavic/httpd-2.2.x-SubstituteInheritBefore-v4_vs_v5.diff
 wrowe notes that rollup 2.2.x patch is not found

  *) mod_proxy: don't recyle backend announced "Connection: close"
connections
 to avoid reusing it should the close be effective after some new
request
 is ready to be sent.
 trunk patch: http://svn.apache.org/r1678763
  http://svn.apache.org/r1703807
  http://svn.apache.org/r1703813
 2.2.x patch:
http://people.apache.org/~ylavic/httpd-2.2.x-mod_proxy-connection_close.patch
 +1: ylavic, rpluem
 ylavic: while at it, I also included r1678763 which is only an
 optimization, but allows to keep code in sync with 2.4/trunk.
 wrowe notes this patch is missing

TestSuite Docs (was Re: [VOTE] Release Apache httpd 2.4.21 as GA)

2016-06-17 Thread Jacob Perkins

I’d love to be able to quickly spin up a new RPM on our Apache & PHP 
distribution and let automated tests slam it. Right now it’s sort of a manual 
process.  A lot of what I’ve seen as far as a ‘how-to’ on setting up Apache 
Test is something like ‘cpan -i Apache::Test’, but I haven’t had great luck 
getting that working 100%.
—
Jacob Perkins
Product Owner
cPanel Inc.

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

> On Jun 16, 2016, at 3:58 PM, olli hauer  wrote:
> 
> Is there somewhere a document how to build and run the test suite?
> (required and enabled modules ...)
> If yes can do some further testing at the weekend

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Regression: mod_http2 continues to process abandoned connection

2016-06-17 Thread Stefan Eissing

Ok, need to verify this tomorrow in order to reproduce and assess. I see from 
your log that the whole thing gets cleaned up eventually. But relying on 
Timeout to save the day is not good...

-Stefan

> Am 17.06.2016 um 16:40 schrieb Michael Kaufmann :
> 
> Hi,
> 
> I have found a regression in mod_http2. When the client stops sending data 
> and closes the connection, mod_http2 doesn't detect that the client has left 
> and continues to "read" request data (until the request times out because of 
> the server's TimeOut value).
> 
> The bug has been introduced with mod_http2 version 1.5.8 (SVN 1747532). It is 
> also present in the httpd 2.4.21 release candidate. mod_http2 version 1.5.7 
> (SVN 1747194) works.
> 
> 
> How to reproduce:
> 
> curl --http2 -k -v --data-binary @bigfile.dat --limit-rate 1 
> https://http2-enabled-apache-server/
> 
> ... then kill the curl process with "kill "
> 
> 
> Log messages:
> 
> h2_session.c(1827): h2_session(66): NO_IO event, 1 streams open
> h2_session.c(1691): AH03078: h2_session(66): transit [BUSY] -- no io --> 
> [WAIT]
> h2_session.c(2260): h2_session: wait for data, 20 micros
> h2_mplx.c(775): h2_mplx(66): trywait on data for 200.00 ms)
> h2_session.c(1691): AH03078: h2_session(66): transit [WAIT] -- wait cycle --> 
> [BUSY]
> h2_filter.c(113): core_input(66): read, NONBLOCK_READ, mode=0, readbytes=8000
> h2_filter.c(164): (104)Connection reset by peer: AH03046: h2_conn_io: error 
> reading
> h2_session.c(1576): (104)Connection reset by peer: h2_session(66): input gone
> h2_session.c(1777): h2_session(66): conn error -> shutdown
> h2_session.c(789): h2_session(66): malloc(120)
> h2_session.c(643): AH03068: h2_session(66): sent FRAME[GOAWAY[error=0, 
> reason='', last_stream=1]], frames=3/3 (r/s)
> h2_session.c(799): h2_session(66): free()
> h2_session.c(799): h2_session(66): free()
> h2_conn_io.c(289): h2_conn_io: pass_output
> h2_conn_io.c(124): bb_dump(66-0)-master conn pass: heap[17] flush
> h2_conn_io.c(309): (32)Broken pipe: AH03044: h2_conn_io(66): pass_out brigade 
> 17 bytes
> h2_session.c(740): AH03069: session(66): sent GOAWAY, err=0, msg=
> h2_session.c(1691): AH03078: h2_session(66): transit [BUSY] -- local goaway 
> --> [LSHUTDOWN]
> h2_mplx.c(1356): h2_mplx(66): dispatch events
> h2_session.c(1827): h2_session(66): NO_IO event, 1 streams open
> h2_session.c(1691): AH03078: h2_session(66): transit [LSHUTDOWN] -- no io --> 
> [WAIT]
> h2_session.c(2260): h2_session: wait for data, 20 micros
> h2_mplx.c(775): h2_mplx(66): trywait on data for 200.00 ms)
> h2_session.c(1691): AH03078: h2_session(66): transit [WAIT] -- wait cycle --> 
> [LSHUTDOWN]
> h2_filter.c(113): core_input(66): read, NONBLOCK_READ, mode=0, readbytes=8000
> h2_filter.c(164): (103)Software caused connection abort: AH03046: h2_conn_io: 
> error reading
> h2_session.c(1576): (103)Software caused connection abort: h2_session(66): 
> input gone
> h2_session.c(1691): AH03078: h2_session(66): transit [LSHUTDOWN] -- conn 
> error --> [DONE]
> h2_mplx.c(1356): h2_mplx(66): dispatch events
> h2_session.c(2312): (70014)End of file found: h2_session(66): [DONE] process 
> returns
> h2_conn_io.c(289): h2_conn_io: pass_output
> h2_conn_io.c(124): bb_dump(66-0)-master conn pass: h2eoc flush
> h2_session.c(963): session(66): cleanup and destroy
> h2_mplx.c(539): h2_mplx(66): release_join with 1 streams open, 0 streams 
> resume, 0 streams ready, 1 tasks
> h2_mplx.c(518): h2_mplx(66-1): exists, started=1, scheduled=1, submitted=0, 
> suspended=0
> h2_mplx.c(402): h2_stream(66-1): done
> h2_mplx.c(567): h2_mplx(66): 2. release_join with 1 streams in hold
> AH03198: h2_mplx(66): release, waiting for 5 seconds now for 1 h2_workers to 
> return, have still 1 tasks outstanding
> ->03198: h2_stream(66-1): POST server /myurl -> ? 0[orph=1/started=1/done=0]
> AH03198: h2_mplx(66): release, waiting for 10 seconds now for 1 h2_workers to 
> return, have still 1 tasks outstanding
> AH03198: h2_mplx(66): release, waiting for 15 seconds now for 1 h2_workers to 
> return, have still 1 tasks outstanding
> AH03198: h2_mplx(66): release, waiting for 20 seconds now for 1 h2_workers to 
> return, have still 1 tasks outstanding
> [...]
> AH03198: h2_mplx(66): release, waiting for 270 seconds now for 1 h2_workers 
> to return, have still 1 tasks outstanding
> AH03198: h2_mplx(66): release, waiting for 275 seconds now for 1 h2_workers 
> to return, have still 1 tasks outstanding
> AH03198: h2_mplx(66): release, waiting for 280 seconds now for 1 h2_workers 
> to return, have still 1 tasks outstanding
> AH03198: h2_mplx(66): release, waiting for 285 seconds now for 1 h2_workers 
> to return, have still 1 tasks outstanding
> h2_task.c(194): (70007)The timeout specified has expired: h2_task(66-1): read 
> returned
> mod_airlock.c(1307): Error reading body data from client (errno = 0)
> h2_from_h1.c(488): h2_from_h1(1): output_filter called
> h2_from_h1.c(551): h2_from_h1(1): removed

Re: Small problem in "configure" script with 2.4.21

2016-06-17 Thread Jens Schleusener


On Fri, 17 Jun 2016, Ruediger Pluem wrote:


I guess the following should fix this:

Index: modules/proxy/config.m4
===
--- modules/proxy/config.m4 (revision 1748670)
+++ modules/proxy/config.m4 (working copy)
@@ -13,6 +13,9 @@
if test "$proxy_mods_enable" = "no"; then
  enable_proxy_hcheck=no
fi
+if test -z "$enable_proxy_hcheck" ; then
+  enable_proxy_hcheck="$proxy_mods_enable"
+fi

proxy_objs="mod_proxy.lo proxy_util.lo"
APACHE_MODULE(proxy, Apache proxy module, $proxy_objs, , $proxy_mods_enable)



Of course you need to run buildconf before your next configure call to 
regenerate configure which
requires you to have Python, autoconf and libtool installed in suitable 
versions.

Regards

Rüdiger


Thanks Rüdiger, that works for me.

Jens



On 06/17/2016 04:09 PM, Jens Schleusener wrote:

Hi,

I just tried to build Apache httpd 2.4.21 using the pre-release test tarball 
under Linux (openSUSE Leap 42.1). But in
contrast to the previous releases my own build wrapper script unfortunately 
failed. I could reproduce the problem by
just using the reduced command

 ./configure  --enable-so --enable-mods-shared=few

that issues

 [... lines deleted ...]
 checking whether to enable mod_proxy_express... no (few)
 checking whether to enable mod_proxy_hcheck... checking dependencies
 configure: WARNING: "mod_watchdog is disabled but required for 
mod_proxy_hcheck"
 checking whether to enable mod_proxy_hcheck... configure: error:
 mod_proxy_hcheck has been requested but can not be built due to prerequisite 
failures

Ok, a "configure --help" mentions

 --enable-proxy-hcheck  reverse-proxy health-check module. Requires
--enable-proxy and --enable-watchdog

but why is the module "proxy-hcheck" enabled while using the option 
"--enable-mods-shared=few"?

Unfortunately the option "--enable-mods-shared=few" seems not well documented 
but it seems to enable for e.g. for 2.4.20
only the modules access_compat, alias, auth_basic, authn_core, authn_file, 
authz_core, authz_groupfile, authz_host,
authz_user, autoindex, dir, env, filter, heaaders, log_config, mime, 
reqtimeout, setenvif, statis, unixd, and version.
But no "proxy"-related modules are included!

A short analysis of the configure script of 2.4.21 let me find the somewhat 
irritating line 23330

 enable_proxy_hcheck=$enable_proxy_hcheck

Comparing the logic about that line with that of the other "proxy"-related 
modules I replaced that line by the more
meaningful (?)

 enable_proxy_hcheck=$proxy_mods_enable

and at least ./configure now runs without errors.

Additionally I found on lines 21591-21593 the in 2.4.21 added related code

 if test "$proxy_mods_enable" = "no"; then
  enable_proxy_hcheck=no
 fi

that seems to me a little bit like an incomplete hack for the errorneous (?) 
line 23330 mentioned above (but I'm not sure).

Regards

Jens

Regression: mod_http2 continues to process abandoned connection

2016-06-17 Thread Michael Kaufmann


Hi,

I have found a regression in mod_http2. When the client stops sending  
data and closes the connection, mod_http2 doesn't detect that the  
client has left and continues to "read" request data (until the  
request times out because of the server's TimeOut value).


The bug has been introduced with mod_http2 version 1.5.8 (SVN  
1747532). It is also present in the httpd 2.4.21 release candidate.  
mod_http2 version 1.5.7 (SVN 1747194) works.



How to reproduce:

curl --http2 -k -v --data-binary @bigfile.dat --limit-rate 1  
https://http2-enabled-apache-server/


... then kill the curl process with "kill "


Log messages:

h2_session.c(1827): h2_session(66): NO_IO event, 1 streams open
h2_session.c(1691): AH03078: h2_session(66): transit [BUSY] -- no io  
--> [WAIT]

h2_session.c(2260): h2_session: wait for data, 20 micros
h2_mplx.c(775): h2_mplx(66): trywait on data for 200.00 ms)
h2_session.c(1691): AH03078: h2_session(66): transit [WAIT] -- wait  
cycle --> [BUSY]

h2_filter.c(113): core_input(66): read, NONBLOCK_READ, mode=0, readbytes=8000
h2_filter.c(164): (104)Connection reset by peer: AH03046: h2_conn_io:  
error reading

h2_session.c(1576): (104)Connection reset by peer: h2_session(66): input gone
h2_session.c(1777): h2_session(66): conn error -> shutdown
h2_session.c(789): h2_session(66): malloc(120)
h2_session.c(643): AH03068: h2_session(66): sent FRAME[GOAWAY[error=0,  
reason='', last_stream=1]], frames=3/3 (r/s)

h2_session.c(799): h2_session(66): free()
h2_session.c(799): h2_session(66): free()
h2_conn_io.c(289): h2_conn_io: pass_output
h2_conn_io.c(124): bb_dump(66-0)-master conn pass: heap[17] flush
h2_conn_io.c(309): (32)Broken pipe: AH03044: h2_conn_io(66): pass_out  
brigade 17 bytes

h2_session.c(740): AH03069: session(66): sent GOAWAY, err=0, msg=
h2_session.c(1691): AH03078: h2_session(66): transit [BUSY] -- local  
goaway --> [LSHUTDOWN]

h2_mplx.c(1356): h2_mplx(66): dispatch events
h2_session.c(1827): h2_session(66): NO_IO event, 1 streams open
h2_session.c(1691): AH03078: h2_session(66): transit [LSHUTDOWN] -- no  
io --> [WAIT]

h2_session.c(2260): h2_session: wait for data, 20 micros
h2_mplx.c(775): h2_mplx(66): trywait on data for 200.00 ms)
h2_session.c(1691): AH03078: h2_session(66): transit [WAIT] -- wait  
cycle --> [LSHUTDOWN]

h2_filter.c(113): core_input(66): read, NONBLOCK_READ, mode=0, readbytes=8000
h2_filter.c(164): (103)Software caused connection abort: AH03046:  
h2_conn_io: error reading
h2_session.c(1576): (103)Software caused connection abort:  
h2_session(66): input gone
h2_session.c(1691): AH03078: h2_session(66): transit [LSHUTDOWN] --  
conn error --> [DONE]

h2_mplx.c(1356): h2_mplx(66): dispatch events
h2_session.c(2312): (70014)End of file found: h2_session(66): [DONE]  
process returns

h2_conn_io.c(289): h2_conn_io: pass_output
h2_conn_io.c(124): bb_dump(66-0)-master conn pass: h2eoc flush
h2_session.c(963): session(66): cleanup and destroy
h2_mplx.c(539): h2_mplx(66): release_join with 1 streams open, 0  
streams resume, 0 streams ready, 1 tasks
h2_mplx.c(518): h2_mplx(66-1): exists, started=1, scheduled=1,  
submitted=0, suspended=0

h2_mplx.c(402): h2_stream(66-1): done
h2_mplx.c(567): h2_mplx(66): 2. release_join with 1 streams in hold
AH03198: h2_mplx(66): release, waiting for 5 seconds now for 1  
h2_workers to return, have still 1 tasks outstanding

->03198: h2_stream(66-1): POST server /myurl -> ? 0[orph=1/started=1/done=0]
AH03198: h2_mplx(66): release, waiting for 10 seconds now for 1  
h2_workers to return, have still 1 tasks outstanding
AH03198: h2_mplx(66): release, waiting for 15 seconds now for 1  
h2_workers to return, have still 1 tasks outstanding
AH03198: h2_mplx(66): release, waiting for 20 seconds now for 1  
h2_workers to return, have still 1 tasks outstanding

[...]
AH03198: h2_mplx(66): release, waiting for 270 seconds now for 1  
h2_workers to return, have still 1 tasks outstanding
AH03198: h2_mplx(66): release, waiting for 275 seconds now for 1  
h2_workers to return, have still 1 tasks outstanding
AH03198: h2_mplx(66): release, waiting for 280 seconds now for 1  
h2_workers to return, have still 1 tasks outstanding
AH03198: h2_mplx(66): release, waiting for 285 seconds now for 1  
h2_workers to return, have still 1 tasks outstanding
h2_task.c(194): (70007)The timeout specified has expired:  
h2_task(66-1): read returned

mod_airlock.c(1307): Error reading body data from client (errno = 0)
h2_from_h1.c(488): h2_from_h1(1): output_filter called
h2_from_h1.c(551): h2_from_h1(1): removed header filter, passing brigade len=0
h2_task.c(355): h2_task(66-1): write response body (0 bytes)
h2_task.c(355): h2_task(66-1): write response body (0 bytes)
h2_task.c(355): h2_task(66-1): write response body (0 bytes)
h2_task.c(343): AH03348: h2_task(66-1): open response to POST iaves60  
/capi/TestServlet

h2_task.c(753): h2_task(66-1): process_request done
h2_task.c(725): h2_task(66-1): processing done
h2_mplx.c(949):

Re: Small problem in "configure" script with 2.4.21

2016-06-17 Thread Ruediger Pluem

I guess the following should fix this:

Index: modules/proxy/config.m4
===
--- modules/proxy/config.m4 (revision 1748670)
+++ modules/proxy/config.m4 (working copy)
@@ -13,6 +13,9 @@
 if test "$proxy_mods_enable" = "no"; then
   enable_proxy_hcheck=no
 fi
+if test -z "$enable_proxy_hcheck" ; then
+  enable_proxy_hcheck="$proxy_mods_enable"
+fi

 proxy_objs="mod_proxy.lo proxy_util.lo"
 APACHE_MODULE(proxy, Apache proxy module, $proxy_objs, , $proxy_mods_enable)



Of course you need to run buildconf before your next configure call to 
regenerate configure which
requires you to have Python, autoconf and libtool installed in suitable 
versions.

Regards

Rüdiger

On 06/17/2016 04:09 PM, Jens Schleusener wrote:
> Hi,
> 
> I just tried to build Apache httpd 2.4.21 using the pre-release test tarball 
> under Linux (openSUSE Leap 42.1). But in
> contrast to the previous releases my own build wrapper script unfortunately 
> failed. I could reproduce the problem by
> just using the reduced command
> 
>  ./configure  --enable-so --enable-mods-shared=few
> 
> that issues
> 
>  [... lines deleted ...]
>  checking whether to enable mod_proxy_express... no (few)
>  checking whether to enable mod_proxy_hcheck... checking dependencies
>  configure: WARNING: "mod_watchdog is disabled but required for 
> mod_proxy_hcheck"
>  checking whether to enable mod_proxy_hcheck... configure: error:
>  mod_proxy_hcheck has been requested but can not be built due to prerequisite 
> failures
> 
> Ok, a "configure --help" mentions
> 
>  --enable-proxy-hcheck  reverse-proxy health-check module. Requires
> --enable-proxy and --enable-watchdog
> 
> but why is the module "proxy-hcheck" enabled while using the option 
> "--enable-mods-shared=few"?
> 
> Unfortunately the option "--enable-mods-shared=few" seems not well documented 
> but it seems to enable for e.g. for 2.4.20
> only the modules access_compat, alias, auth_basic, authn_core, authn_file, 
> authz_core, authz_groupfile, authz_host,
> authz_user, autoindex, dir, env, filter, heaaders, log_config, mime, 
> reqtimeout, setenvif, statis, unixd, and version.
> But no "proxy"-related modules are included!
> 
> A short analysis of the configure script of 2.4.21 let me find the somewhat 
> irritating line 23330
> 
>  enable_proxy_hcheck=$enable_proxy_hcheck
> 
> Comparing the logic about that line with that of the other "proxy"-related 
> modules I replaced that line by the more
> meaningful (?)
> 
>  enable_proxy_hcheck=$proxy_mods_enable
> 
> and at least ./configure now runs without errors.
> 
> Additionally I found on lines 21591-21593 the in 2.4.21 added related code
> 
>  if test "$proxy_mods_enable" = "no"; then
>   enable_proxy_hcheck=no
>  fi
> 
> that seems to me a little bit like an incomplete hack for the errorneous (?) 
> line 23330 mentioned above (but I'm not sure).
> 
> Regards
> 
> Jens
>

Small problem in "configure" script with 2.4.21

2016-06-17 Thread Jens Schleusener


Hi,

I just tried to build Apache httpd 2.4.21 using the pre-release test 
tarball under Linux (openSUSE Leap 42.1). But in contrast to the previous 
releases my own build wrapper script unfortunately failed. I could 
reproduce the problem by just using the reduced command


 ./configure  --enable-so --enable-mods-shared=few

that issues

 [... lines deleted ...]
 checking whether to enable mod_proxy_express... no (few)
 checking whether to enable mod_proxy_hcheck... checking dependencies
 configure: WARNING: "mod_watchdog is disabled but required for 
mod_proxy_hcheck"
 checking whether to enable mod_proxy_hcheck... configure: error:
 mod_proxy_hcheck has been requested but can not be built due to prerequisite 
failures

Ok, a "configure --help" mentions

 --enable-proxy-hcheck  reverse-proxy health-check module. Requires
--enable-proxy and --enable-watchdog

but why is the module "proxy-hcheck" enabled while using the option 
"--enable-mods-shared=few"?


Unfortunately the option "--enable-mods-shared=few" seems not well 
documented but it seems to enable for e.g. for 2.4.20 only the modules 
access_compat, alias, auth_basic, authn_core, authn_file, authz_core, 
authz_groupfile, authz_host, authz_user, autoindex, dir, env, filter, 
heaaders, log_config, mime, reqtimeout, setenvif, statis, unixd, and 
version. But no "proxy"-related modules are included!


A short analysis of the configure script of 2.4.21 let me find the 
somewhat irritating line 23330


 enable_proxy_hcheck=$enable_proxy_hcheck

Comparing the logic about that line with that of the other "proxy"-related 
modules I replaced that line by the more meaningful (?)


 enable_proxy_hcheck=$proxy_mods_enable

and at least ./configure now runs without errors.

Additionally I found on lines 21591-21593 the in 2.4.21 added related 
code


 if test "$proxy_mods_enable" = "no"; then
  enable_proxy_hcheck=no
 fi

that seems to me a little bit like an incomplete hack for the 
errorneous (?) line 23330 mentioned above (but I'm not sure).


Regards

Jens

Re: Question about mod_sed

2016-06-17 Thread Rainer Jung


Am 17.06.2016 um 12:00 schrieb Ruediger Pluem:



On 06/16/2016 10:33 PM, Christophe JAILLET wrote:

Hi,


I'm not familiar with sed implementation, but 'copy_to_genbuf' looks spurious.

Actually it only expands a buffer if some space is needed, but nothing is 
copied.


Should it look like:

static void copy_to_genbuf(sed_eval_t *eval, const char* sz)
{
int len = strlen(sz);
unsigned int reqsize = len + 1;
if (eval->gsize < reqsize) {
grow_gen_buffer(eval, reqsize, NULL);
}
memcpy(eval->gspend, sz, len + 1);


The above does a copy, or do I miss your point?


I think Christophe added the memcpy and the below lines as a suggestion 
("Should it look like").



/* hspend will now point to NULL character */
eval->gspend += len;
}


Regards,

Rainer

Re: Question about mod_sed

2016-06-17 Thread Ruediger Pluem



On 06/17/2016 02:24 PM, Marion et Christophe JAILLET wrote:
> Hi,
> 
>  
> 
> The code in trunk and 2.4 don't have the 3 last lines:
> 
>memcpy(eval->gspend, sz, len + 1);
>/* hspend will now point to NULL character */
>eval->gspend += len;
> 
>  
> 
> See:
> 
>
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/sed1.c?revision=1326984=markup#l231
> 
>  
> 
>  
> 
> The code in my first post is what I think is correct.
> 
> Sorry for not being clear.

Sorry for not reading your mail correctly :-). It was in there.
Yes, I agree that the copy stuff is missing. Weird. Nevertheless I think

eval->gspend += len;

in your proposal is wrong as eval->gspend looks like the buffer base pointer
for me that should not be changed.

Regards

Rüdiger

> 
>  
> 
> CJ
> 
> > Message du 17/06/16 12:00
> > De : "Ruediger Pluem" 
> > A : dev@httpd.apache.org
> > Copie à :
> > Objet : Re: Question about mod_sed
> >
> >
> >
> > On 06/16/2016 10:33 PM, Christophe JAILLET wrote:
> > > Hi,
> > >
> > >
> > > I'm not familiar with sed implementation, but 'copy_to_genbuf' looks 
> spurious.
> > >
> > > Actually it only expands a buffer if some space is needed, but 
> nothing is copied.
> > >
> > >
> > > Should it look like:
> > >
> > > static void copy_to_genbuf(sed_eval_t *eval, const char* sz)
> > > {
> > > int len = strlen(sz);
> > > unsigned int reqsize = len + 1;
> > > if (eval->gsize < reqsize) {
> > > grow_gen_buffer(eval, reqsize, NULL);
> > > }
> > > memcpy(eval->gspend, sz, len + 1);
> >
> > The above does a copy, or do I miss your point?
> >
> > > /* hspend will now point to NULL character */
> > > eval->gspend += len;
> > > }
> >
> > Regards
> >
> > Rüdiger
> > 
>

Re: Question about mod_sed

2016-06-17 Thread Marion et Christophe JAILLET

Hi,

 

The code in trunk and 2.4 don't have the 3 last lines:

   memcpy(eval->gspend, sz, len + 1);
   /* hspend will now point to NULL character */
   eval->gspend += len;

 

See:

   
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/sed1.c?revision=1326984=markup#l231

 

 

The code in my first post is what I think is correct. 

Sorry for not being clear.

 

CJ

> Message du 17/06/16 12:00
> De : "Ruediger Pluem" 
> A : dev@httpd.apache.org
> Copie à : 
> Objet : Re: Question about mod_sed
> 
> 
> 
> On 06/16/2016 10:33 PM, Christophe JAILLET wrote:
> > Hi,
> > 
> > 
> > I'm not familiar with sed implementation, but 'copy_to_genbuf' looks 
> > spurious.
> > 
> > Actually it only expands a buffer if some space is needed, but nothing is 
> > copied.
> > 
> > 
> > Should it look like:
> > 
> > static void copy_to_genbuf(sed_eval_t *eval, const char* sz)
> > {
> > int len = strlen(sz);
> > unsigned int reqsize = len + 1;
> > if (eval->gsize < reqsize) {
> > grow_gen_buffer(eval, reqsize, NULL);
> > }
> > memcpy(eval->gspend, sz, len + 1);
> 
> The above does a copy, or do I miss your point?
> 
> > /* hspend will now point to NULL character */
> > eval->gspend += len;
> > }
> 
> Regards
> 
> Rüdiger
>

Re: Question about mod_sed

2016-06-17 Thread Ruediger Pluem



On 06/16/2016 10:33 PM, Christophe JAILLET wrote:
> Hi,
> 
> 
> I'm not familiar with sed implementation, but 'copy_to_genbuf' looks spurious.
> 
> Actually it only expands a buffer if some space is needed, but nothing is 
> copied.
> 
> 
> Should it look like:
> 
> static void copy_to_genbuf(sed_eval_t *eval, const char* sz)
> {
> int len = strlen(sz);
> unsigned int reqsize = len + 1;
> if (eval->gsize < reqsize) {
> grow_gen_buffer(eval, reqsize, NULL);
> }
> memcpy(eval->gspend, sz, len + 1);

The above does a copy, or do I miss your point?

> /* hspend will now point to NULL character */
> eval->gspend += len;
> }

Regards

Rüdiger

Re: [VOTE] Release Apache httpd 2.4.21 as GA

2016-06-17 Thread Noel Butler


On 17/06/2016 03:07, Jim Jagielski wrote:

The pre-release test tarballs for Apache httpd 2.4.21 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.21 GA.

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



slackware 13.1 -> -current with APR 1.5.2 and APR-Util 1.5.4, and with 
mysql

all good.


(this will be last release I'll test with anything under slackware 14.0
but the older versions should still be fine)

Thanks Jim.

--
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.21 as GA

Re: [VOTE] Release Apache httpd 2.4.21 as GA

Re: [VOTE] Release Apache httpd 2.4.21 as GA

Re: Hung 2.2.x STATUS entries...

Re: Small problem in "configure" script with 2.4.21

Re: [VOTE] Release Apache httpd 2.4.21 as GA

Re: TestSuite Docs (was Re: [VOTE] Release Apache httpd 2.4.21 as GA)

Hung 2.2.x STATUS entries...

TestSuite Docs (was Re: [VOTE] Release Apache httpd 2.4.21 as GA)

Re: Regression: mod_http2 continues to process abandoned connection

Re: Small problem in "configure" script with 2.4.21

Regression: mod_http2 continues to process abandoned connection

Re: Small problem in "configure" script with 2.4.21

Small problem in "configure" script with 2.4.21

Re: Question about mod_sed

Re: Question about mod_sed

Re: Question about mod_sed

Re: Question about mod_sed

Re: [VOTE] Release Apache httpd 2.4.21 as GA

19 matches

Site Navigation

Mail list logo

Footer information