Re: [VOTE] Release httpd-2.4.47

[Ruediger Pluem]

On 4/29/21 6:36 PM, Roy T. Fielding wrote:
> On Apr 29, 2021, at 5:18 AM, Ruediger Pluem  > wrote:

>> Probably we are doing it wrong and should not touch ANY of the headers for 
>> 304 and instead need to fix
>>
>> modules/cache/cache_storage::cache_accept_headers
>>
>> such that we don't update the following headers of the cached entity:
>>
>> Content-Encoding
>> Content-Length
>> Content-MD5
>> Content-Range
>> ETag
> 
> Yes.

I am confused now. The explicit list of headers was stripped down to 
Content-Length in
https://github.com/httpwg/http-core/pull/490/files.

Instead there is the sentence "Header fields that the cache's stored 
representation of the response depends upon, as described
below,". The mentioned description lists Content-Encoding and hints that 
further Content-* fields may be omitted. ETag is not
mentioned at all.

Regards

Rüdiger

Re: [VOTE] Release httpd-2.4.47

[Ruediger Pluem]

On 4/29/21 6:36 PM, Roy T. Fielding wrote:
> On Apr 29, 2021, at 5:18 AM, Ruediger Pluem  > wrote:
>> On 4/29/21 2:09 PM, Eric Covener wrote:
>>> On Thu, Apr 29, 2021 at 7:40 AM Ivan Zhakov >> > wrote:
 I have noticed regression in ETag response header handling in httpd 
 2.4.47: ETag response header is not set for HTTP 304
 responses. While RFC 7232, 4.1 requires them for 304 responses [1]
 [[[
 The server generating a 304 response MUST generate any of the
 following header fields that would have been sent in a 200 (OK)
 response to the same request: Cache-Control, Content-Location,
 Date, ETag, Expires, and Vary.
 ]]]

 httpd 2.4.46 and before sets ETag header for HTTP 304 responses.

 Unfortunately, I don't have time right now to investigate this issue 
 further, but I think it's a critical regression for the
 patch release.

 [1] https://tools.ietf.org/html/rfc7232#section-4.1

>>>
>>> Thanks for catching, I have revived the BZ thread here:
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=61820
>>> In the issue  we were working from a draft of the caching RFC, maybe
>>> part of how we got mixed up.
>>
>> Probably we are doing it wrong and should not touch ANY of the headers for 
>> 304 and instead need to fix
>>
>> modules/cache/cache_storage::cache_accept_headers
>>
>> such that we don't update the following headers of the cached entity:
>>
>> Content-Encoding
>> Content-Length
>> Content-MD5
>> Content-Range
>> ETag
> 
> Yes.
> 
>> Given the current state I would wait announcing the release until this got 
>> clarified and if we got it wrong fixed.
> 
> It's hard to tell what the current state is based on a bunch of deltas,
> which is why I don't like discussions in bugzilla. Yes, it looks like people
> keep getting confused on what should be *generated* on a 304 versus
> what should be updated in a cache for 304.
> 
> As I said before, the bug is in removing header fields from a 304
> response in the HTTP filter just as it is being sent. That is wrong and
> unnecessary. It's not the HTTP filter's job to remove information
> from a message (unless the filter itself is generating the message,
> as in a canned error response).
> 
> The spec says SHOULD NOT send unnecessary metadata because
> there are cases when they might need to be sent. Just remove the
> entire conditional and let the generating code adhere to the spec.
> 
> Note that the current specs are in 
> 
>   
> https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#status.304

Thanks as always for the clarification. I would propose the following next 
steps:

1. Don't announce 2.4.47
2. Fix the HTTP filter such that it does not remove headers from 304 responses.
3. Release 2.4.48 with this fix

If there is enough time before 3. we might fix  
modules/cache/cache_storage::cache_accept_headers to not update the following
headers on a 304:

Content-Encoding
Content-Length
Content-MD5
Content-Range
ETag

If not it will be part of 2.4.49 as it is "just" a bug and not a regression.

Regards

Rüdiger

Re: [VOTE] Release httpd-2.4.47

[Roy T. Fielding]

On Apr 29, 2021, at 5:18 AM, Ruediger Pluem  wrote:
> On 4/29/21 2:09 PM, Eric Covener wrote:
>> On Thu, Apr 29, 2021 at 7:40 AM Ivan Zhakov  wrote:
>>> I have noticed regression in ETag response header handling in httpd 2.4.47: 
>>> ETag response header is not set for HTTP 304 responses. While RFC 7232, 4.1 
>>> requires them for 304 responses [1]
>>> [[[
>>> The server generating a 304 response MUST generate any of the
>>> following header fields that would have been sent in a 200 (OK)
>>> response to the same request: Cache-Control, Content-Location,
>>> Date, ETag, Expires, and Vary.
>>> ]]]
>>> 
>>> httpd 2.4.46 and before sets ETag header for HTTP 304 responses.
>>> 
>>> Unfortunately, I don't have time right now to investigate this issue 
>>> further, but I think it's a critical regression for the patch release.
>>> 
>>> [1] https://tools.ietf.org/html/rfc7232#section-4.1
>>> 
>> 
>> Thanks for catching, I have revived the BZ thread here:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=61820
>> In the issue  we were working from a draft of the caching RFC, maybe
>> part of how we got mixed up.
> 
> Probably we are doing it wrong and should not touch ANY of the headers for 
> 304 and instead need to fix
> 
> modules/cache/cache_storage::cache_accept_headers
> 
> such that we don't update the following headers of the cached entity:
> 
> Content-Encoding
> Content-Length
> Content-MD5
> Content-Range
> ETag

Yes.

> Given the current state I would wait announcing the release until this got 
> clarified and if we got it wrong fixed.

It's hard to tell what the current state is based on a bunch of deltas,
which is why I don't like discussions in bugzilla. Yes, it looks like people
keep getting confused on what should be *generated* on a 304 versus
what should be updated in a cache for 304.

As I said before, the bug is in removing header fields from a 304
response in the HTTP filter just as it is being sent. That is wrong and
unnecessary. It's not the HTTP filter's job to remove information
from a message (unless the filter itself is generating the message,
as in a canned error response).

The spec says SHOULD NOT send unnecessary metadata because
there are cases when they might need to be sent. Just remove the
entire conditional and let the generating code adhere to the spec.

Note that the current specs are in 

  
https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#status.304
 


Roy

Re: [VOTE] Release httpd-2.4.47

[Ruediger Pluem]

On 4/29/21 2:09 PM, Eric Covener wrote:
> On Thu, Apr 29, 2021 at 7:40 AM Ivan Zhakov  wrote:
>>
>> On Thu, 22 Apr 2021 at 12:25, Christophe JAILLET 
>>  wrote:
>>>
>>> Hi, all;
>>> Please find below the proposed release tarball and signatures:
>>> https://dist.apache.org/repos/dist/dev/httpd/
>>>
>>> I would like to call a VOTE over the next few days to release this
>>> candidate tarball as 2.4.47:
>>> [ ] +1: It's not just good, it's good enough!
>>> [ ] +0: Let's have a talk.
>>> [X] -1: There's trouble in paradise. Here's what's wrong.
>>>
>>> The computed digests of the tarball up for vote are:
>>> sha1: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz
>>> sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34
>>> *httpd-2.4.47.tar.gz
>>> sha512:
>>> de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3
>>> *httpd-2.4.47.tar.gz
>>>
>>> The SVN tag is '2.4.47' at r1889091.
>>>
>>
>> [ Sorry for the late response. I've been offline. ]
>>
>> I have noticed regression in ETag response header handling in httpd 2.4.47: 
>> ETag response header is not set for HTTP 304 responses. While RFC 7232, 4.1 
>> requires them for 304 responses [1]
>> [[[
>> The server generating a 304 response MUST generate any of the
>> following header fields that would have been sent in a 200 (OK)
>> response to the same request: Cache-Control, Content-Location,
>> Date, ETag, Expires, and Vary.
>> ]]]
>>
>> httpd 2.4.46 and before sets ETag header for HTTP 304 responses.
>>
>> Unfortunately, I don't have time right now to investigate this issue 
>> further, but I think it's a critical regression for the patch release.
>>
>> [1] https://tools.ietf.org/html/rfc7232#section-4.1
>>
> 
> Thanks for catching, I have revived the BZ thread here:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61820
> In the issue  we were working from a draft of the caching RFC, maybe
> part of how we got mixed up.

Probably we are doing it wrong and should not touch ANY of the headers for 304 
and instead need to fix

modules/cache/cache_storage::cache_accept_headers

such that we don't update the following headers of the cached entity:

Content-Encoding
Content-Length
Content-MD5
Content-Range
ETag

Given the current state I would wait announcing the release until this got 
clarified and if we got it wrong fixed.

Regards

Rüdiger



> 

Re: [VOTE] Release httpd-2.4.47

[Eric Covener]

On Thu, Apr 29, 2021 at 7:40 AM Ivan Zhakov  wrote:
>
> On Thu, 22 Apr 2021 at 12:25, Christophe JAILLET 
>  wrote:
>>
>> Hi, all;
>> Please find below the proposed release tarball and signatures:
>> https://dist.apache.org/repos/dist/dev/httpd/
>>
>> I would like to call a VOTE over the next few days to release this
>> candidate tarball as 2.4.47:
>> [ ] +1: It's not just good, it's good enough!
>> [ ] +0: Let's have a talk.
>> [X] -1: There's trouble in paradise. Here's what's wrong.
>>
>> The computed digests of the tarball up for vote are:
>> sha1: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz
>> sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34
>> *httpd-2.4.47.tar.gz
>> sha512:
>> de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3
>> *httpd-2.4.47.tar.gz
>>
>> The SVN tag is '2.4.47' at r1889091.
>>
>
> [ Sorry for the late response. I've been offline. ]
>
> I have noticed regression in ETag response header handling in httpd 2.4.47: 
> ETag response header is not set for HTTP 304 responses. While RFC 7232, 4.1 
> requires them for 304 responses [1]
> [[[
> The server generating a 304 response MUST generate any of the
> following header fields that would have been sent in a 200 (OK)
> response to the same request: Cache-Control, Content-Location,
> Date, ETag, Expires, and Vary.
> ]]]
>
> httpd 2.4.46 and before sets ETag header for HTTP 304 responses.
>
> Unfortunately, I don't have time right now to investigate this issue further, 
> but I think it's a critical regression for the patch release.
>
> [1] https://tools.ietf.org/html/rfc7232#section-4.1
>

Thanks for catching, I have revived the BZ thread here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=61820
In the issue  we were working from a draft of the caching RFC, maybe
part of how we got mixed up.

Re: [VOTE] Release httpd-2.4.47

[Ivan Zhakov]

On Thu, 22 Apr 2021 at 12:25, Christophe JAILLET <
christophe.jail...@wanadoo.fr> wrote:

> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.47:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [X] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz
> sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34
> *httpd-2.4.47.tar.gz
> sha512:
> de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3
>
> *httpd-2.4.47.tar.gz
>
> The SVN tag is '2.4.47' at r1889091.
>
>
[ Sorry for the late response. I've been offline. ]

I have noticed regression in ETag response header handling in httpd 2.4.47:
ETag response header is not set for HTTP 304 responses. While RFC 7232, 4.1
requires them for 304 responses [1]
[[[
The server generating a 304 response MUST generate any of the
following header fields that would have been sent in a 200 (OK)
response to the same request: Cache-Control, Content-Location,
Date, ETag, Expires, and Vary.
]]]

httpd 2.4.46 and before sets ETag header for HTTP 304 responses.

Unfortunately, I don't have time right now to investigate this issue
further, but I think it's a critical regression for the patch release.

[1] https://tools.ietf.org/html/rfc7232#section-4.1

-- 
Ivan Zhakov

Re: [VOTE] Release httpd-2.4.47

[Christophe JAILLET]

Le 22/04/2021 à 11:25, Christophe JAILLET a écrit :

Hi, all;
   Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this 
candidate tarball as 2.4.47:

[X] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.



+1 for me as well.

Tested on Ubuntu 21.04
gcc 11.0.1
maintainer-mode
APR latest 1.7.x branch (i.e 1.7.0+)
APR-UTIL latest 1.6.x branch (i.e 1.6.1+)
Tested with event, prefork, worker

Nothing special.

Test coverage data is more or less the same as for 2.4.44. A few modules 
have a slightly better coverage (mod_lua, mod_proxy_wstunnel) which 
looks logical according to change history in the test framework.


Detailed gcov data available on demand if anyone is interested.


CJ

Re: [VOTE] Release httpd-2.4.47

[Mario Brandt]

+1 on debian 10

On Thu, 22 Apr 2021 at 11:25, Christophe JAILLET
 wrote:
>
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.47:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz
> sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34
> *httpd-2.4.47.tar.gz
> sha512:
> de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3
> *httpd-2.4.47.tar.gz
>
> The SVN tag is '2.4.47' at r1889091.
>
> --
> Christophe JAILLET

Re: [VOTE] Release httpd-2.4.47

[Steffen]

+1 for release on Windows. 

> Op 22 apr. 2021 om 11:25 heeft Christophe JAILLET 
>  het volgende geschreven:
> 
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.47:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> sha1: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz
> sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34 
> *httpd-2.4.47.tar.gz
> sha512: 
> de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3
>  *httpd-2.4.47.tar.gz
> 
> The SVN tag is '2.4.47' at r1889091.
> 
> --
> Christophe JAILLET

Re: [VOTE] Release httpd-2.4.47

[Rainer Jung]

Am 22.04.2021 um 11:25 schrieb Christophe JAILLET:

Hi, all;
   Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this 
candidate tarball as 2.4.47:

[ ] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.

The computed digests of the tarball up for vote are:
sha1: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz
sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34 
*httpd-2.4.47.tar.gz
sha512: 
de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3 
*httpd-2.4.47.tar.gz


The SVN tag is '2.4.47' at r1889091.

--
Christophe JAILLET



+1 to release and thanks a bunch for stepping in as RM!

I think I wasn't able to import your key from a pgp key server, but 
maybe I wasn't using the right ones. Your key is in the KEYS file, 
probably just not in the network of key servers.


Summary: all OK except for

- one single crash on SLES 11 using prefork.

Detailed report:

- Sigs and hashes OK
- contents of tarballs identical
- contents of tag and tarballs identical
  except for expected deltas

Built on

- Solaris 10 Sparc as 32 Bit Binaries
- SLES 11+12+15 (64 Bits)
- RHEL 6+7+8 (64 Bits)

For all platforms built

- with default (shared) and static modules
- with module set reallyall
- using --enable-load-all-modules
- against
  - bundled APR/APU from deps tarball
  - external APR/APU 1.7.0/1.6.1 (expat)
  - APR/APU 1.6.5/1.6.1 (expat)
  - APR/APU 1.7.x r1889104/1.7.x r1884108 (expat)
  - APR/APU 1.7.x r1889104/1.7.x r1884108 (libxml2)
  - APR/APU 1.6.x r1876940/1.6.x r1876943 (expat)
  - APR/APU 1.6.x r1876940/1.6.x r1876943 (libxml2)

- using external libraries
  - expat 2.3.0
  - pcre 8.44
  - lua 5.4.3 (compiled with LUA_COMPAT_MODULE)
  - libxml2 2.9.10
  - libnghttp2 1.43.0
  - brotli 1.0.9
  - curl 7.76.1
  - jansson 2.13.1
  - libldap 2.4.58
and
  - openssl 0.9.8zh, 1.0.2, 1.0.2u, 1.1.1, 1.1.1k, 3.0.0alpha15

- Tool chain:
- platform gcc except on Solaris
  (gcc 9.3.0 Solaris 10)
- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
  - on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE,
-D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__
and -D_XPG6

All of the 852 builds done until now succeeded, 32 builds on Solaris yet 
to come.


- compiler warnings:

  - only on Solaris 10 Sparc (GCC 9.3.0): APR 1.7.x
srclib/apr/locks/unix/proc_mutex.c:979:49: warning: 
'mutex_proc_pthread_cond_methods' defined but not used 
[-Wunused-const-variable=]
=> the declaration checks for APR_USE_PROC_PTHREAD_MUTEX_COND, 
which is defined on Solaris, the use in line 1437 also checks 
HAVE_PTHREAD_MUTEX_ROBUST, which is not defined on Solaris.


  - deprecation warnings when building against OpenSSL 3.0.0, see other 
mail



Tested for

- SLES 11+12+15, RHEL 6+7+8
  - Tests for Solaris 10 Sparc still to come, when builds finish there
- MPMs prefork, worker, event
- default and static module builds
- log level trace8
- module set reallyall (129 modules plus 3 MPMs)
- Perl client bundle build against OpenSSL 1.1.1g plus patches, 1.1.0l, 
1.0.2u and 0.9.8zh

- OpenSSL once linked statically and once as a shared library

Every OpenSSL version in the client is tested with every OpenSSL version 
in the server.


The total number of test suite runs until now is ~3800 (many more still 
to come, especially those with statically linked OpenSSL and most of the 
Solaris ones).


Some local adjustments to tests were used:

- t/modules/buffer.t: removing huge buffer tests
  -my $bigsize = 10;
  +my $bigsize = 1;

- fixing limitrequestline overwrite which does not yet really work in 
Apache-Test/lib/Apache/TestConfig.pm

87d86
 'global LimitRequestLine setting (default is 128)',
96a96
> #   limitrequestline => 'global LimitRequestLine setting (default is 
128)',

372,373c372,373
< $vars->{limitrequestline} ||= 128;
< $vars->{limitrequestlinex2} = 2 * $vars->{limitrequestline};
---
> #$vars->{limitrequestline} ||= 128;
> #$vars->{limitrequestlinex2} = 2 * $vars->{limitrequestline};

- temporary workaround for a OpenSSL 3 when using "openssl crl -hash" 
with STDIN in Apache-Test/lib/Apache/TestSSLCA.pm

39a40
> my $openssl_workaround = $ENV{APACHE_TEST_OPENSSL_CMD_WORKAROUND} || 
$openssl;

426c427
< chomp(my $hash = `$openssl $type -noout -hash < $file`);
---
> chomp(my $hash = `$openssl_workaround $type -noout -hash < 
$file`);


This enables to use OpenSSL 3 everywhere in test suite configuration and 
setup and override it only in the CRL hash command line, for which it is 
currently buggy.


The following test failures were seen:

a All https tests fail between OpenSSL 0.9.8zh and 3.0.0alpha15
  Not a regression.
  Probably need to figure out how to

Re: [VOTE] Release httpd-2.4.47

[Yann Ylavic]

>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.47:

[X] +1: It's not just good, it's good enough!

All tests are ok on my Debian(s) 9, 10, 11.
All good for sigs and digests too.

Thanks a lot Christophe!

Re: [VOTE] Release httpd-2.4.47

[Daniel]

Hello,

I tested it compiling in RHEL 6.9 (a bit legacy I know) along with
also manually compiled:
openssl-1.1.1k
expat-2.2.10
apr-1.7.0
apr-util-1.6.1
pcre-8.44
nghttp2-1.43.0 (and to compile this , compiled Python-3.9.4)
bonus: tested loading weblogic plugin too (WebLogic Server Plugin
version 12.2.1.4.0 )

Results: no issues.

I also tested the same scenario as above with CentOS 7.9.

Results: No issues either.

So FWIW although the setup I mention may not be orthodox at all:

+1 for me.

El jue, 22 abr 2021 a las 11:25, Christophe JAILLET
() escribió:
>
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.47:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz
> sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34
> *httpd-2.4.47.tar.gz
> sha512:
> de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3
> *httpd-2.4.47.tar.gz
>
> The SVN tag is '2.4.47' at r1889091.
>
> --
> Christophe JAILLET



-- 
Daniel

Re: [VOTE] Release httpd-2.4.47

[Noel Butler]

On 22/04/2021 19:25, Christophe JAILLET wrote:


Hi, all;
Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this 
candidate tarball as 2.4.47:

[ ] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.


all good on  Slackware 14.0, 14.2 and 15 beta (aka -current)

caveat:

Building --with-included-apr  w/mariadb 10.5 (>10.2?) will fail unless 
apr-util is patched, a patch to resolve has been in apr-util svn for 15 
months :)


http://svn.apache.org/viewvc?rev=1872061&view=rev

Again, this is apr related, not http, so not a blocker, just a "FYI"

--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

Re: [VOTE] Release httpd-2.4.47

[Giovanni Bechis]

On 4/22/21 11:25 AM, Christophe JAILLET wrote:
> Hi, all;
>    Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release this candidate 
> tarball as 2.4.47:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> sha1: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz
> sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34 
> *httpd-2.4.47.tar.gz
> sha512: 
> de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3
>  *httpd-2.4.47.tar.gz
> 
> The SVN tag is '2.4.47' at r1889091.
> 
+1, works fine on Fedora33 and OpenBSD 6.9.

Thanks for taking up the RM.
 Giovanni



OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Release httpd-2.4.47

[Jan Ehrhardt]

Christophe JAILLET in gmane.comp.apache.devel (Thu, 22 Apr 2021 11:25:01
+0200):
>[x] +1: It's not just good, it's good enough!

FWIW tested on Windows:
- VC9  x86
- VC15 x64

The latter is running on my dev-server right now. I especially tested if
mod_md works as expected in both versions, because I have to renew a lot
of LetsEncrypt certificates on my production server next week.
-- 
Jan

Re: [VOTE] Release httpd-2.4.47

[Joe Orton]

On Thu, Apr 22, 2021 at 11:25:01AM +0200, Christophe JAILLET wrote:
> Hi, all;
>Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release this candidate
> tarball as 2.4.47:
> [X] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.

Huge thanks for taking up the RM reins.

+1 from me, passes test suite on Fedora 33 and RHEL8.  CHANGES looks 
good.  Travis passed for the second release tag in a row, a good omen? 
https://travis-ci.com/github/apache/httpd/builds/223831396

Regards, Joe

Re: [VOTE] Release httpd-2.4.47

[Dennis Clarke]

On 4/22/21 7:44 PM, Eric Covener wrote:
> On Thu, Apr 22, 2021 at 7:31 PM Dennis Clarke  wrote:
>>
>> On 4/22/21 6:10 PM, Eric Covener wrote:
>>> On Thu, Apr 22, 2021 at 5:25 AM Christophe JAILLET
>>>  wrote:

 Hi, all;
 Please find below the proposed release tarball and signatures:
 https://dist.apache.org/repos/dist/dev/httpd/

 I would like to call a VOTE over the next few days to release this
 candidate tarball as 2.4.47:
 [ ] +1: It's not just good, it's good enough!
 [ ] +0: Let's have a talk.
 [ ] -1: There's trouble in paradise. Here's what's wrong.

 The computed digests of the tarball up for vote are:
 sha1: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz
 sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34
 *httpd-2.4.47.tar.gz
 sha512:
 de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3
 *httpd-2.4.47.tar.gz

 The SVN tag is '2.4.47' at r1889091.
>>>
>>> +1 tested on AIX/xlc/PPC64 with only the usual failures on my system.
>>>
>>> Thanks for stepping up to RM!
>>>
>>
>> Was that ppc64 big-endian ?
> 
> Yes, BE
> 
> 

Oh, wonderful.

Glad to hear that some of us are still running BE servers. The little
bugs that can shake loose therein are often a surprise.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: [VOTE] Release httpd-2.4.47

[Eric Covener]

On Thu, Apr 22, 2021 at 7:31 PM Dennis Clarke  wrote:
>
> On 4/22/21 6:10 PM, Eric Covener wrote:
> > On Thu, Apr 22, 2021 at 5:25 AM Christophe JAILLET
> >  wrote:
> >>
> >> Hi, all;
> >> Please find below the proposed release tarball and signatures:
> >> https://dist.apache.org/repos/dist/dev/httpd/
> >>
> >> I would like to call a VOTE over the next few days to release this
> >> candidate tarball as 2.4.47:
> >> [ ] +1: It's not just good, it's good enough!
> >> [ ] +0: Let's have a talk.
> >> [ ] -1: There's trouble in paradise. Here's what's wrong.
> >>
> >> The computed digests of the tarball up for vote are:
> >> sha1: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz
> >> sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34
> >> *httpd-2.4.47.tar.gz
> >> sha512:
> >> de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3
> >> *httpd-2.4.47.tar.gz
> >>
> >> The SVN tag is '2.4.47' at r1889091.
> >
> > +1 tested on AIX/xlc/PPC64 with only the usual failures on my system.
> >
> > Thanks for stepping up to RM!
> >
>
> Was that ppc64 big-endian ?

Yes, BE


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

Re: [VOTE] Release httpd-2.4.47

[Dennis Clarke]

On 4/22/21 6:10 PM, Eric Covener wrote:
> On Thu, Apr 22, 2021 at 5:25 AM Christophe JAILLET
>  wrote:
>>
>> Hi, all;
>> Please find below the proposed release tarball and signatures:
>> https://dist.apache.org/repos/dist/dev/httpd/
>>
>> I would like to call a VOTE over the next few days to release this
>> candidate tarball as 2.4.47:
>> [ ] +1: It's not just good, it's good enough!
>> [ ] +0: Let's have a talk.
>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>
>> The computed digests of the tarball up for vote are:
>> sha1: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz
>> sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34
>> *httpd-2.4.47.tar.gz
>> sha512:
>> de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3
>> *httpd-2.4.47.tar.gz
>>
>> The SVN tag is '2.4.47' at r1889091.
> 
> +1 tested on AIX/xlc/PPC64 with only the usual failures on my system.
> 
> Thanks for stepping up to RM!
> 

Was that ppc64 big-endian ?  I have ppc64 big endian here running Debian
Linux as well as SPARC64. Also I am working on Solaris 10 on ye Fujitsu
SPARC64 as well as FreeBSD on RISC-V and a few others. This will take me
some time. Hope there are more than a few days for testing.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: [VOTE] Release httpd-2.4.47

[Eric Covener]

On Thu, Apr 22, 2021 at 5:25 AM Christophe JAILLET
 wrote:
>
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.47:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz
> sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34
> *httpd-2.4.47.tar.gz
> sha512:
> de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3
> *httpd-2.4.47.tar.gz
>
> The SVN tag is '2.4.47' at r1889091.

+1 tested on AIX/xlc/PPC64 with only the usual failures on my system.

Thanks for stepping up to RM!