Re: [VOTE] Release httpd-2.4.35
On Mon, 17 Sep 2018 19:56:52 -0500 Daniel Ruggeri wrote: > Hi, all; > Please find below the proposed release tarball and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ > Builds fine (once I'd found a keyserver that would talk to my gpg today), but the tests bombed on me. Unlikely to have time to dig into that before at least Friday, so no vote likely unless you leave it open all week or thereabouts. -- Nick Kew
Re: [VOTE] Release httpd-2.4.35
Wow - that's actually really cool! Thanks for sharing - would love to see a HOWTO. -- Daniel Ruggeri On 2018-09-19 14:59, Christophe JAILLET wrote: Le 18/09/2018 à 02:56, Daniel Ruggeri 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.35: [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. The computed digests of the tarball up for vote are: md5: 92ddccfbd43b533578499d1faaad17fe *httpd-2.4.35.tar.gz sha1: b7996c2c1f7ff5bb217114fe5354a19a5207ab62 *httpd-2.4.35.tar.gz sha256: 31c2c82c9cd34749cbb60d04619d9aa3fb0814ab22246ad588d2426dde90c72c *httpd-2.4.35.tar.gz +1 Ubuntu 18.04 gcc 8.1 I now build with gcc test-coverage options. Attached, the results on my machine after a t/TEST. I use a slightly modified version of the script I've updated for APR. (don't pay attention to all the APR related text in the attached file :)) This gives the picture of what need more love in the test-framework. I can share the corresponding .gcov files to see which lines are never executed while running the tests. This still need to be improved and I will post one day a How-To about it. Based on it, I'll try to add some new test-cases to improve the test coverage of the test-framework. (i.e. see my latest additions for modules that were completely untested (reflector.t; allowmethods.t) or some paths not tested (setenvif.t)) We'll never be able to test all possible combination, but the more lines are executed at least one, the better it is. Thx for RM CJ
Re: [VOTE] Release httpd-2.4.35
+1: It's not just good, it's good enough! Tested on Debian(s) 7/8/9/10, MPM event/worker/prefork, APR 1.6.5, OpenSSL 1.0.1 => 1.1.0. Thanks Daniel.
Re: [VOTE] Release httpd-2.4.35
Le 18/09/2018 à 02:56, Daniel Ruggeri 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.35: [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. The computed digests of the tarball up for vote are: md5: 92ddccfbd43b533578499d1faaad17fe *httpd-2.4.35.tar.gz sha1: b7996c2c1f7ff5bb217114fe5354a19a5207ab62 *httpd-2.4.35.tar.gz sha256: 31c2c82c9cd34749cbb60d04619d9aa3fb0814ab22246ad588d2426dde90c72c *httpd-2.4.35.tar.gz +1 Ubuntu 18.04 gcc 8.1 I now build with gcc test-coverage options. Attached, the results on my machine after a t/TEST. I use a slightly modified version of the script I've updated for APR. (don't pay attention to all the APR related text in the attached file :)) This gives the picture of what need more love in the test-framework. I can share the corresponding .gcov files to see which lines are never executed while running the tests. This still need to be improved and I will post one day a How-To about it. Based on it, I'll try to add some new test-cases to improve the test coverage of the test-framework. (i.e. see my latest additions for modules that were completely untested (reflector.t; allowmethods.t) or some paths not tested (setenvif.t)) We'll never be able to test all possible combination, but the more lines are executed at least one, the better it is. Thx for RM CJ Title: Test Coverage Get Involved CVS Mailing Lists Snapshots Build on Win32 Build on Unix Download! from a mirror Docs APR APR-util APR-iconv Guidelines Project Guidelines Contributing Version Numbers Miscellaneous License Projects using APR APR Test Coverage This should give us some idea of how well our tests actually stress our code. To generate this data, do the following: ./buildconf CFLAGS="-fprofile-arcs -ftest-coverage ./configure make cd test make ./testall cd .. make gcov Note that this will only generate test coverage data for the testall script, but all tests should be moving to the unified framework, so this is correct. mod_access_compat 81.94% tested mod_allowmethods 89.36% tested mod_auth_basic 55.79% tested mod_auth_digest 54.15% tested mod_auth_form 52.02% tested mod_authn_anon 75.00% tested mod_authn_core 37.27% tested mod_authn_dbd 8.55% tested mod_authn_dbm 22.22% tested mod_authn_file 85.48% tested mod_authn_socache 16.38% tested mod_authnz_fcgi 3.72% tested mod_authz_core 64.05% tested mod_authz_dbd 6.47% tested mod_authz_dbm 13.13% tested mod_authz_groupfile 62.50% tested mod_authz_host 14.29% tested mod_authz_owner 7.14% tested mod_authz_user 33.33% tested mod_unixd 32.41% tested mod_isapi 0.00% tested cache_storage 36.46% tested cache_util 41.47% tested mod_cache_disk 65.26% tested mod_cache 41.65% tested mod_cache_socache 5.58% tested mod_file_cache 18.80% tested mod_socache_dbm 1.43% tested mod_socache_memcache 4.86% tested mod_socache_shmcb 1.05% tested mod_heartbeat 16.25% tested mod_heartmonitor 6.22% tested mod_macro 0.00% tested mod_watchdog 66.19% tested mod_dbd 12.60% tested dbm 22.44% tested lock 57.92% tested mod_dav_fs 66.67% tested repos 34.00% tested locks 0.00% tested mod_dav_lock 23.81% tested liveprop 89.58% tested mod_dav 22.22% tested props 44.19% tested providers 33.33% tested std_liveprop 43.75% tested util 41.75% tested util_lock 59.07% tested mod_bucketeer 87.10% tested mod_dumpio 21.33% tested mod_echo 89.87% tested mod_case_filter 86.49% tested mod_case_filter_in 83.72% tested mod_example_hooks 0.00% tested mod_example_ipc 0.00% tested mod_brotli 53.53% tested mod_buffer 7.56% tested mod_charset_lite 6.47% tested mod_data 3.80% tested mod_deflate 41.54% tested mod_ext_filter 59.66% tested mod_filter 50.73% tested mod_include 75.20% tested mod_proxy_html 7.25% tested mod_ratelimit 48.76% tested mod_reflector 86.11% tested mod_reqtimeout 63.44% tested mod_request 13.10% tested mod_sed 3.06% tested mod_substitute 80.13% tested mod_xml2enc 0.00% tested regexp 0.00% tested sed0 0.00% tested sed1 0.00% tested mod_asis 58.14% tested mod_autoindex 42.69% tested mod_cgid 74.51% tested mod_cgi 8.19% tested mod_info 83.73% tested mod_status 65.29% tested mod_suexec 65.71% tested h2_alt_svc 19.23% tested h2_bucket_beam 73.98% tested h2_bucket_eos 74.29%
Re: [VOTE] Release httpd-2.4.35
On Mon, Sep 17, 2018 at 8:57 PM Daniel Ruggeri 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.35: > [ ] +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, AIX/xlc/ppc64 w/ openssl 1.1.1 (1.1.0 has issues on AIX) Not 100% but as good as can be expected on my aging perl+prereqs For posterity: Test Summary Report --- t/ab/base.t (Wstat: 0 Tests: 5 Failed: 4) Failed tests: 1-4 t/modules/http2.t (Wstat: 0 Tests: 24 Failed: 0) Parse errors: Bad plan. You planned 52 tests but ran 24. t/ssl/proxy.t (Wstat: 0 Tests: 172 Failed: 118) Failed tests: 1-59, 114-172 t/ssl/varlookup.t (Wstat: 9 Tests: 74 Failed: 0) Non-zero exit status: -1 Parse errors: Bad plan. You planned 83 tests but ran 74. Files=123, Tests=8537, 3811 wallclock secs ( 2.60 usr 0.36 sys + 49.25 cusr 22.23 csys = 74.44 CPU) Result: FAIL Failed 4/123 test programs. 122/8537 subtests failed. [warning] server localhost:8529 shutdown
Re: [VOTE] Release httpd-2.4.35
On 09/19/2018 01:18 PM, Gregg Smith wrote: On 9/17/2018 5:56 PM, Daniel Ruggeri 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 ... Nothing seen working on Solaris x86 or SPARC yet and I have yet to really throw myself at it. Don't let it hold anything back. I hardly see it as a large percentage of the user space anyways. I'll look at it starting later today. Dennis Clarke
Re: [VOTE] Release httpd-2.4.35
All fine here on Windows. > Op 18 sep. 2018 om 02:56 heeft Daniel Ruggeri 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.35: > [ ] +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: > md5: 92ddccfbd43b533578499d1faaad17fe *httpd-2.4.35.tar.gz > sha1: b7996c2c1f7ff5bb217114fe5354a19a5207ab62 *httpd-2.4.35.tar.gz > sha256: 31c2c82c9cd34749cbb60d04619d9aa3fb0814ab22246ad588d2426dde90c72c > *httpd-2.4.35.tar.gz > > -- > Daniel Ruggeri >
Re: [VOTE] Release httpd-2.4.35
On 9/17/2018 5:56 PM, Daniel Ruggeri 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.35: [ ] +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 on Windows w/ apr/1.6.5, apu/1.6.1 vc11 32 & 64 bit w/ OpenSSL 1.0.2p vc14 32 & 64 bit w/ OpenSSL 1.0.2p & 1.1.0i Thanks for RMing Daniel
Re: trunk proxy_http failures
Can try tomorrow. > Am 19.09.2018 um 17:49 schrieb Jim Jagielski : > > Does folding > http://home.apache.org/~ylavic/patches/2.4.x-mpms_async_objects_lifetime.patch > into 2.4.x make any difference?? > >> On Sep 19, 2018, at 10:10 AM, Stefan Eissing >> wrote: >> >> Hi, >> >> the h2 test suite has tests with http/2 in the front and a standard >> proxy_http to localhost. When running the test suite against trunk, the >> tests run into a failed GET on a proxy. The request hangs 5 seconds and the >> fails reading the status line, as seen below. The proxy is defined as: >> >> >> BalancerMember "https://127.0.0.1:SUBST_PORT_HTTPS_SUBST; hcmethod=GET >> hcuri=/ >> >> ... >> ProxyPass "/proxy" "balancer://http-local" >> ProxyPassReverse "/proxy" "balancer://http-local" >> >> Typical log: >> [Wed Sep 19 14:02:58.038602 2018] [http2:trace1] [pid 35806:tid >> 123145377832960] h2_task.c(675): [client 127.0.0.1:64231] h2_task(200-13): >> start process_request >> [Wed Sep 19 14:02:58.038654 2018] [proxy:debug] [pid 35806:tid >> 123145377832960] proxy_util.c(1326): AH10122: proxy: Entering byrequests for >> BALANCER (balancer://https-local) >> [Wed Sep 19 14:02:58.038679 2018] [proxy:debug] [pid 35806:tid >> 123145377832960] proxy_util.c(1418): AH10123: proxy: byrequests selected >> worker "https://127.0.0.1:12346; : busy 0 : lbstatus 100 >> [Wed Sep 19 14:02:58.038694 2018] [proxy:debug] [pid 35806:tid >> 123145377832960] proxy_util.c(1971): AH00924: worker https://127.0.0.1:12346 >> shared already initialized >> [Wed Sep 19 14:02:58.038712 2018] [proxy:debug] [pid 35806:tid >> 123145377832960] proxy_util.c(2028): AH00926: worker https://127.0.0.1:12346 >> local already initialized >> [Wed Sep 19 14:02:58.038736 2018] [proxy:debug] [pid 35806:tid >> 123145377832960] mod_proxy.c(1258): [client 127.0.0.1:64231] AH01143: >> Running scheme balancer handler (attempt 0) >> [Wed Sep 19 14:02:58.038756 2018] [proxy:debug] [pid 35806:tid >> 123145377832960] proxy_util.c(2367): AH00942: HTTPS: has acquired connection >> for (127.0.0.1) >> [Wed Sep 19 14:02:58.038775 2018] [proxy:debug] [pid 35806:tid >> 123145377832960] proxy_util.c(2421): [client 127.0.0.1:64231] AH00944: >> connecting https://127.0.0.1:12346/files/data-1m to 127.0.0.1:12346 >> [Wed Sep 19 14:02:58.038790 2018] [proxy:debug] [pid 35806:tid >> 123145377832960] proxy_util.c(2630): [client 127.0.0.1:64231] AH00947: >> connected /files/data-1m to 127.0.0.1:12346 >> [Wed Sep 19 14:03:03.041506 2018] [proxy_http:error] [pid 35806:tid >> 123145377832960] (70014)End of file found: [client 127.0.0.1:64231] AH01102: >> error reading status line from remote server 127.0.0.1:12346 >> [Wed Sep 19 14:03:03.041541 2018] [proxy_http:debug] [pid 35806:tid >> 123145377832960] mod_proxy_http.c(1386): [client 127.0.0.1:64231] AH01104: >> Closing connection to client because reading from backend server >> 127.0.0.1:12346 failed. Number of keepalives 1 >> >> What can I best do to further debug this? >> >> Should I disable the balancer and see if the problem persists? >> >> Help appreciated, thanks! >> >> -Stefan >
Re: trunk proxy_http failures
> Am 19.09.2018 um 17:12 schrieb Yann Ylavic : > > On Wed, Sep 19, 2018 at 4:46 PM Stefan Eissing > wrote: >> >> Thanks, Yann, this helped me pin the problem down further: >> >> - with disablereuse=on everything works fine >> - with ttl=1 the problem is still there > > Is the KeepAliveTimeout on the backend side above 1 (second)? Yes, upped it to 20, no difference. >> >> and then: >> - with mpm_worker, the problem also disappears (no disable/ttl needed) > > Hmm, something (new?) which does not respect KA timeout on MPM event... > Can you confirm this (for instance with tcpdump or alike)? I will debug more tomorrow. As usual, timing seems to play a role. Basically there is a sequence of 3 requests in play which repeat with different content: 1. POST (no expect), small request body 2. POST (expect-100-cont), upload.py body is 1k/10k/100k/ file 3. GET on files/data-1k etc. The requests are done in this order, not parallel. All on a new connection. If a request fails, it is always 3 and always with proxy re-using a dead connection. So, assuming it is the same proxy connection that gets re-used, what may cause the connection to close after request 2? That is runs on mpm_worker *may* point to mpm_event. But with "LogLevel core:trace8" it seems to disappear in event, also. With core:trace6 it still happens... Strange thing. Btw. Solving this is not urgent for me. I see this only in trunk. Let's see if I gain more insight tomorrow on this. Cheers, Stefan > >> >> These tests were running since the dawn of h2 time and are still running in >> 2.4.x. Since the problem also goes away on worker, this looks like a new >> problem with mpm_event and connection closing (keepalive)? > > I'm having a look at it, will come back if something pops up.
Re: trunk proxy_http failures
Does folding http://home.apache.org/~ylavic/patches/2.4.x-mpms_async_objects_lifetime.patch into 2.4.x make any difference?? > On Sep 19, 2018, at 10:10 AM, Stefan Eissing > wrote: > > Hi, > > the h2 test suite has tests with http/2 in the front and a standard > proxy_http to localhost. When running the test suite against trunk, the tests > run into a failed GET on a proxy. The request hangs 5 seconds and the fails > reading the status line, as seen below. The proxy is defined as: > > >BalancerMember "https://127.0.0.1:SUBST_PORT_HTTPS_SUBST; hcmethod=GET > hcuri=/ > >... >ProxyPass "/proxy" "balancer://http-local" >ProxyPassReverse "/proxy" "balancer://http-local" > > Typical log: > [Wed Sep 19 14:02:58.038602 2018] [http2:trace1] [pid 35806:tid > 123145377832960] h2_task.c(675): [client 127.0.0.1:64231] h2_task(200-13): > start process_request > [Wed Sep 19 14:02:58.038654 2018] [proxy:debug] [pid 35806:tid > 123145377832960] proxy_util.c(1326): AH10122: proxy: Entering byrequests for > BALANCER (balancer://https-local) > [Wed Sep 19 14:02:58.038679 2018] [proxy:debug] [pid 35806:tid > 123145377832960] proxy_util.c(1418): AH10123: proxy: byrequests selected > worker "https://127.0.0.1:12346; : busy 0 : lbstatus 100 > [Wed Sep 19 14:02:58.038694 2018] [proxy:debug] [pid 35806:tid > 123145377832960] proxy_util.c(1971): AH00924: worker https://127.0.0.1:12346 > shared already initialized > [Wed Sep 19 14:02:58.038712 2018] [proxy:debug] [pid 35806:tid > 123145377832960] proxy_util.c(2028): AH00926: worker https://127.0.0.1:12346 > local already initialized > [Wed Sep 19 14:02:58.038736 2018] [proxy:debug] [pid 35806:tid > 123145377832960] mod_proxy.c(1258): [client 127.0.0.1:64231] AH01143: Running > scheme balancer handler (attempt 0) > [Wed Sep 19 14:02:58.038756 2018] [proxy:debug] [pid 35806:tid > 123145377832960] proxy_util.c(2367): AH00942: HTTPS: has acquired connection > for (127.0.0.1) > [Wed Sep 19 14:02:58.038775 2018] [proxy:debug] [pid 35806:tid > 123145377832960] proxy_util.c(2421): [client 127.0.0.1:64231] AH00944: > connecting https://127.0.0.1:12346/files/data-1m to 127.0.0.1:12346 > [Wed Sep 19 14:02:58.038790 2018] [proxy:debug] [pid 35806:tid > 123145377832960] proxy_util.c(2630): [client 127.0.0.1:64231] AH00947: > connected /files/data-1m to 127.0.0.1:12346 > [Wed Sep 19 14:03:03.041506 2018] [proxy_http:error] [pid 35806:tid > 123145377832960] (70014)End of file found: [client 127.0.0.1:64231] AH01102: > error reading status line from remote server 127.0.0.1:12346 > [Wed Sep 19 14:03:03.041541 2018] [proxy_http:debug] [pid 35806:tid > 123145377832960] mod_proxy_http.c(1386): [client 127.0.0.1:64231] AH01104: > Closing connection to client because reading from backend server > 127.0.0.1:12346 failed. Number of keepalives 1 > > What can I best do to further debug this? > > Should I disable the balancer and see if the problem persists? > > Help appreciated, thanks! > > -Stefan
Re: Write a module to overwrite HTTP methods handling
Hi Nick, Thank you for your answer. I guess module for CGI would be a guideline for what I need to do. I just want to double check whether I am on the right track or not. So when a HTTP request with a query string is received, in my mind, the only way to handle it is the CGI which would in turn run an executable file with given parameters in the query string that has been parsed by the server. I am wondering if all HTTP methods, such as GET/DELETE/PUT/POST, etc. are handled in CGI or this is only GET? Also, would I be able to use CGI module and tailor it for my usage to handle a received request as I wish e.g. establishing a connection to a database or do something else based on the query string? Thanks for your help, Danesh Daroui On Wed, Sep 19, 2018 at 4:51 PM Nick Kew wrote: > > > > On 19 Sep 2018, at 13:57, Danesh Daroui wrote: > > > > Hi all, > > > > I am sorry if my question is a bit off! I am wondering whether it is > > possible to write a server module that can handle different HTTP > > methods in a customized way? > > Of course it's possible, and indeed common: see for example mod_dav, > or even the oldest application module of all, mod_cgi. > > However, your question leads me to wonder if what you're looking for > might not be better accomplished in configuration. If you need > functionality that isn't already supported, that would call for a new > module (or equivalent), but you'd use configuration to determine > when it should or shouldn't be invoked to process a request. > > -- > Nick Kew
Re: NOTICE: Intent to T 2.4.35 in the next few hours
On Wed, Sep 19, 2018 at 6:56 AM Joe Orton wrote: > On Wed, Sep 19, 2018 at 01:19:29PM +0200, Apache Lounge wrote: > > Are there examples what (maybe) does not work with OpenSSL 1.1.1 ? > > Have you run the test suite? The flipped setting of SSL_MODE_AUTO_RETRY > is expected to break TLSv1.2 as well, that problem is consistent with > the hangs Daniel reported here. > Note this applies specifically to the timing and scope of httpd auth under TLS. > > openssl.org says that the new 1.1.1 is binary and API/ABI compatible > with > > OpenSSL 1.1.0. > > For some apps that might be true, I think it's a bit of a stretch, but > it's not really worth arguing about. > And note that 1.1.1a may address some deficiencies in 1.1.1 release w.r.t. compatibility. Although this specific one was asked-and-answered, with enough pushback from various projects, such defaults (at least for the behavior of TLS 1.2) may be reconsidered. +1 on the proposed statement.
Re: minor nit in mod_ssl
On Wed, Sep 19, 2018 at 6:39 AM Stefan Eissing wrote: > > > Am 18.09.2018 um 15:44 schrieb Houser, Rick : > > > > In the same vein, I’ve been running this patch on our builds to get > around a warning for certificates not matching the hostname. Certificates > are not expected to match the hostname with many load balancing/uptime > detection schemes, and this one logs a LOT when it trips on every vhost. > Perhaps this patch should share the same fate as decided for the TLS > missing SNI issue? > > Not sure I understand your setup here. Is this the ServerName from the > global server? Otherwise, in a VirtualHost why would you not set the > ServerName to the hostname you are serving? Envision a TCP load balancer routing TLS-crypted traffic across a number of internal hosts, with each of the named virtual hosts presenting the correct certificate, and known to httpd by their ServerAlias on the outer-facing interface. Not terminated at the edge balancer. There is the issue of keeping TLS session key encoding in sync across the backends, obviously.
Re: trunk proxy_http failures
On Wed, Sep 19, 2018 at 4:46 PM Stefan Eissing wrote: > > Thanks, Yann, this helped me pin the problem down further: > > - with disablereuse=on everything works fine > - with ttl=1 the problem is still there Is the KeepAliveTimeout on the backend side above 1 (second)? > > and then: > - with mpm_worker, the problem also disappears (no disable/ttl needed) Hmm, something (new?) which does not respect KA timeout on MPM event... Can you confirm this (for instance with tcpdump or alike)? > > These tests were running since the dawn of h2 time and are still running in > 2.4.x. Since the problem also goes away on worker, this looks like a new > problem with mpm_event and connection closing (keepalive)? I'm having a look at it, will come back if something pops up.
Re: Write a module to overwrite HTTP methods handling
> On 19 Sep 2018, at 13:57, Danesh Daroui wrote: > > Hi all, > > I am sorry if my question is a bit off! I am wondering whether it is > possible to write a server module that can handle different HTTP > methods in a customized way? Of course it's possible, and indeed common: see for example mod_dav, or even the oldest application module of all, mod_cgi. However, your question leads me to wonder if what you're looking for might not be better accomplished in configuration. If you need functionality that isn't already supported, that would call for a new module (or equivalent), but you'd use configuration to determine when it should or shouldn't be invoked to process a request. -- Nick Kew
Re: trunk proxy_http failures
Thanks, Yann, this helped me pin the problem down further: - with disablereuse=on everything works fine - with ttl=1 the problem is still there and then: - with mpm_worker, the problem also disappears (no disable/ttl needed) These tests were running since the dawn of h2 time and are still running in 2.4.x. Since the problem also goes away on worker, this looks like a new problem with mpm_event and connection closing (keepalive)? Anything I can do to give you good data? Some preferred log settings? -Stefan > Am 19.09.2018 um 16:32 schrieb Yann Ylavic : > > On Wed, Sep 19, 2018 at 4:10 PM Stefan Eissing > wrote: >> >> >>BalancerMember "https://127.0.0.1:SUBST_PORT_HTTPS_SUBST; >> hcmethod=GET hcuri=/ > > Does disablereuse=on help here? > >> >>... >>ProxyPass "/proxy" "balancer://http-local" >>ProxyPassReverse "/proxy" "balancer://http-local" >> >> Typical log: > ... >> [Wed Sep 19 14:02:58.038790 2018] [proxy:debug] [pid 35806:tid >> 123145377832960] proxy_util.c(2630): [client 127.0.0.1:64231] AH00947: >> connected /files/data-1m to 127.0.0.1:12346 >> [Wed Sep 19 14:03:03.041506 2018] [proxy_http:error] [pid 35806:tid >> 123145377832960] (70014)End of file found: [client 127.0.0.1:64231] AH01102: >> error reading status line from remote server 127.0.0.1:12346 > > I suspect mod_proxy is reusing a connection already close by 127.0.0.1:12346. > If you know the KeepAliveTimeout configured there, setting a ttl= to a > lower value on the BalancerMember could be less radical than > disablereuse... > > HTH, > Yann.
Re: trunk proxy_http failures
On Wed, Sep 19, 2018 at 4:10 PM Stefan Eissing wrote: > > > BalancerMember "https://127.0.0.1:SUBST_PORT_HTTPS_SUBST; > hcmethod=GET hcuri=/ Does disablereuse=on help here? > > ... > ProxyPass "/proxy" "balancer://http-local" > ProxyPassReverse "/proxy" "balancer://http-local" > > Typical log: ... > [Wed Sep 19 14:02:58.038790 2018] [proxy:debug] [pid 35806:tid > 123145377832960] proxy_util.c(2630): [client 127.0.0.1:64231] AH00947: > connected /files/data-1m to 127.0.0.1:12346 > [Wed Sep 19 14:03:03.041506 2018] [proxy_http:error] [pid 35806:tid > 123145377832960] (70014)End of file found: [client 127.0.0.1:64231] AH01102: > error reading status line from remote server 127.0.0.1:12346 I suspect mod_proxy is reusing a connection already close by 127.0.0.1:12346. If you know the KeepAliveTimeout configured there, setting a ttl= to a lower value on the BalancerMember could be less radical than disablereuse... HTH, Yann.
trunk proxy_http failures
Hi, the h2 test suite has tests with http/2 in the front and a standard proxy_http to localhost. When running the test suite against trunk, the tests run into a failed GET on a proxy. The request hangs 5 seconds and the fails reading the status line, as seen below. The proxy is defined as: BalancerMember "https://127.0.0.1:SUBST_PORT_HTTPS_SUBST; hcmethod=GET hcuri=/ ... ProxyPass "/proxy" "balancer://http-local" ProxyPassReverse "/proxy" "balancer://http-local" Typical log: [Wed Sep 19 14:02:58.038602 2018] [http2:trace1] [pid 35806:tid 123145377832960] h2_task.c(675): [client 127.0.0.1:64231] h2_task(200-13): start process_request [Wed Sep 19 14:02:58.038654 2018] [proxy:debug] [pid 35806:tid 123145377832960] proxy_util.c(1326): AH10122: proxy: Entering byrequests for BALANCER (balancer://https-local) [Wed Sep 19 14:02:58.038679 2018] [proxy:debug] [pid 35806:tid 123145377832960] proxy_util.c(1418): AH10123: proxy: byrequests selected worker "https://127.0.0.1:12346; : busy 0 : lbstatus 100 [Wed Sep 19 14:02:58.038694 2018] [proxy:debug] [pid 35806:tid 123145377832960] proxy_util.c(1971): AH00924: worker https://127.0.0.1:12346 shared already initialized [Wed Sep 19 14:02:58.038712 2018] [proxy:debug] [pid 35806:tid 123145377832960] proxy_util.c(2028): AH00926: worker https://127.0.0.1:12346 local already initialized [Wed Sep 19 14:02:58.038736 2018] [proxy:debug] [pid 35806:tid 123145377832960] mod_proxy.c(1258): [client 127.0.0.1:64231] AH01143: Running scheme balancer handler (attempt 0) [Wed Sep 19 14:02:58.038756 2018] [proxy:debug] [pid 35806:tid 123145377832960] proxy_util.c(2367): AH00942: HTTPS: has acquired connection for (127.0.0.1) [Wed Sep 19 14:02:58.038775 2018] [proxy:debug] [pid 35806:tid 123145377832960] proxy_util.c(2421): [client 127.0.0.1:64231] AH00944: connecting https://127.0.0.1:12346/files/data-1m to 127.0.0.1:12346 [Wed Sep 19 14:02:58.038790 2018] [proxy:debug] [pid 35806:tid 123145377832960] proxy_util.c(2630): [client 127.0.0.1:64231] AH00947: connected /files/data-1m to 127.0.0.1:12346 [Wed Sep 19 14:03:03.041506 2018] [proxy_http:error] [pid 35806:tid 123145377832960] (70014)End of file found: [client 127.0.0.1:64231] AH01102: error reading status line from remote server 127.0.0.1:12346 [Wed Sep 19 14:03:03.041541 2018] [proxy_http:debug] [pid 35806:tid 123145377832960] mod_proxy_http.c(1386): [client 127.0.0.1:64231] AH01104: Closing connection to client because reading from backend server 127.0.0.1:12346 failed. Number of keepalives 1 What can I best do to further debug this? Should I disable the balancer and see if the problem persists? Help appreciated, thanks! -Stefan
Re: svn commit: r1841330 - in /httpd/httpd/branches/2.4.x: ./ STATUS modules/http2/h2_bucket_beam.c modules/http2/h2_from_h1.c modules/http2/h2_h2.c modules/http2/h2_headers.c modules/http2/h2_mplx.c
Thanks, Jim! > Am 19.09.2018 um 14:55 schrieb j...@apache.org: > > Author: jim > Date: Wed Sep 19 12:55:26 2018 > New Revision: 1841330 > > URL: http://svn.apache.org/viewvc?rev=1841330=rev > Log: > Merge r1835118 from trunk: > > On the trunk: > > * silencing gcc uninitialized warning > * refrainning from apr_table_addn() use since pool debug assumptions are in > conflict > * adding more assertions > * copy-porting changes to base64 encoding code from mod_md > > > Submitted by: icing > Reviewed by: icing, minfrin, jim > > Modified: >httpd/httpd/branches/2.4.x/ (props changed) >httpd/httpd/branches/2.4.x/STATUS >httpd/httpd/branches/2.4.x/modules/http2/h2_bucket_beam.c >httpd/httpd/branches/2.4.x/modules/http2/h2_from_h1.c >httpd/httpd/branches/2.4.x/modules/http2/h2_h2.c >httpd/httpd/branches/2.4.x/modules/http2/h2_headers.c >httpd/httpd/branches/2.4.x/modules/http2/h2_mplx.c >httpd/httpd/branches/2.4.x/modules/http2/h2_proxy_session.c >httpd/httpd/branches/2.4.x/modules/http2/h2_util.c > > Propchange: httpd/httpd/branches/2.4.x/ > -- > --- svn:mergeinfo (original) > +++ svn:mergeinfo Wed Sep 19 12:55:26 2018 > @@ -8,4 +8,4 @@ > /httpd/httpd/branches/trunk-md:1804087-1804529 > /httpd/httpd/branches/trunk-override-index:1793921-1793931 > /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,1341905-1341906,1341913,1341930,1342065,1343085,1343087,1343094,1343099,1343109,1343935,1344712,1345147,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,1369 >
Write a module to overwrite HTTP methods handling
Hi all, I am sorry if my question is a bit off! I am wondering whether it is possible to write a server module that can handle different HTTP methods in a customized way? I mean, if I want to perform some action when GET with some specific parameters comes in and/or PUT, POST or DELETE as well, can I add handlers (which would preferably overwrite the original handler) or I have to hack into the server code where HTTP methods are handled? I have actually found where these methods are handled (in default_handler inside protocol.c) but I am not sure whether this is the best way to do so or not since rebasing to the master would be be problematic when my local branch diverges as time goes by. At the same time, I believe that modules are to add extra features e.g. authentication methods, compression techniques, encryption, server management, etc, and not altering basic functionality of the server or maybe it is possible since SSL is also implemented in a module? I would appreciate if you guide me through this. Regards, Danesh Daroui
Re: NOTICE: Intent to T 2.4.35 in the next few hours
On Wed, Sep 19, 2018 at 01:19:29PM +0200, Apache Lounge wrote: > Are there examples what (maybe) does not work with OpenSSL 1.1.1 ? Have you run the test suite? The flipped setting of SSL_MODE_AUTO_RETRY is expected to break TLSv1.2 as well, that problem is consistent with the hangs Daniel reported here. > openssl.org says that the new 1.1.1 is binary and API/ABI compatible with > OpenSSL 1.1.0. For some apps that might be true, I think it's a bit of a stretch, but it's not really worth arguing about. Regards, Joe
Re: minor nit in mod_ssl
> Am 18.09.2018 um 15:44 schrieb Houser, Rick :
>
> In the same vein, I’ve been running this patch on our builds to get around a
> warning for certificates not matching the hostname. Certificates are not
> expected to match the hostname with many load balancing/uptime detection
> schemes, and this one logs a LOT when it trips on every vhost. Perhaps this
> patch should share the same fate as decided for the TLS missing SNI issue?
>
> --- httpd-2.4.10_backup/modules/ssl/ssl_engine_init.c 2015-09-30
> 07:50:30.0 -0400
> +++ httpd-2.4.10/modules/ssl/ssl_engine_init.c_new 2015-10-19
> 16:13:51.716000988 -0400
> @@ -1002,7 +1002,7 @@
>
> if (modssl_X509_match_name(ptemp, cert, (const char *)s->server_hostname,
> TRUE, s) == FALSE) {
> -ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, APLOGNO(01909)
> +ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(01909)
> "%s server certificate does NOT include an ID "
> "which matches the server name", key_id);
> }
>
Not sure I understand your setup here. Is this the ServerName from the global
server? Otherwise, in a VirtualHost why would you not set the ServerName to the
hostname you are serving?
-Stefan
>
> Rick Houser
> Web Engineer
>
> From: William A Rowe Jr
> Sent: Monday, September 17, 2018 16:27
> To: httpd
> Subject: Re: minor nit in mod_ssl
>
> EXTERNAL EMAIL
>
>
> On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing
> wrote:
> >
> > mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when
> > strict_sni_vhost_check is enabled and a request comes in without SNI.
> >
> > Question: is a downgrade from ERR to INFO/DEBUG backportable or do we
> > consider this a break of compatibility?
>
>
>
> On Mon, Sep 17, 2018 at 10:43 AM William A Rowe Jr
> wrote:
> >
> > It is entirely appropriate to turn down the volume. That's what
> > module-by-module loglevels are there for.
>
>
> This is the loglevel of typical garbage request streams;
>
> [Mon Sep 17 11:44:43.036820 2018] [core:debug] [pid 26317:tid
> 140199172134656] protocol.c(965): (20014)Internal error (specific information
> not available): [client 127.0.0.1:34974] Failed to read request header line
> (null)
> [Mon Sep 17 11:44:43.036871 2018] [core:debug] [pid 26317:tid
> 140199172134656] protocol.c(1318): [client127.0.0.1:34974] AH00567: request
> failed: error reading the headers
> [Mon Sep 17 15:24:46.146311 2018] [core:debug] [pid 26413:tid
> 140199180527360] protocol.c(860): [client127.0.0.1:35330] AH02418: HTTP
> Request Line; Unrecognized protocol 'HTTP/1.xx' (perhaps whitespace was
> injected?)
>
> It seems that TLS missing SNI fits this same debug-level pattern of
> diagnostics.
Re: NOTICE: Intent to T 2.4.35 in the next few hours
Are there examples what (maybe) does not work with OpenSSL 1.1.1 ? Build 2.4.35 with OpenSSL 1.1.1, no issues seen/reported. More then A week ago I ask already the community to test 2.4.34 with OpenSSL 1.1.1 also no issue reported. Plan to ship 2.4.35 with OpenSSL1.1.1 With our announcement I put the note: Apache 2.4.35 does not support yet TLSv1.3, expected in 2.4.36 release.. Note: openssl.org says that the new 1.1.1 is binary and API/ABI compatible with OpenSSL 1.1.0. I can confirm that sofar and also windows PHP-guys. On Wednesday 19/09/2018 at 12:54, Joe Orton wrote: On Tue, Sep 18, 2018 at 11:19:10AM -0500, William A Rowe Jr wrote: On Tue, Sep 18, 2018 at 2:43 AM Joe Orton wrote: You'll likely see issues testing against OpenSSL 1.1.1 until the TLSv1.3 merge is integrated for 2.4.x, yeah, I wouldn't worry about that. But I think this is worth highlighting in our Announcement, that we would strongly caution users to build 2.4.35 against OpenSSL 1.1.0. (And we could tease the forthcoming 2.4 release as building against 1.1.1/TLS 1.3.) Good idea. How about this, to insert after the "This release requires the Apache Portable Runtime (APR)," paragraph? """ This release is compatible with OpenSSL versions from 0.9.8a to 1.1.0 only, and does not support TLSv1.3. Future releases of httpd 2.4 are expected to add compatibility with OpenSSL 1.1.1 and enable support for TLSv1.3. """ Regards, Joe
Re: NOTICE: Intent to T 2.4.35 in the next few hours
+1 > Am 19.09.2018 um 12:54 schrieb Joe Orton : > > On Tue, Sep 18, 2018 at 11:19:10AM -0500, William A Rowe Jr wrote: >> On Tue, Sep 18, 2018 at 2:43 AM Joe Orton wrote: >>> You'll likely see issues testing against OpenSSL 1.1.1 until the TLSv1.3 >>> merge is integrated for 2.4.x, yeah, I wouldn't worry about that. >> >> But I think this is worth highlighting in our Announcement, that we would >> strongly caution users to build 2.4.35 against OpenSSL 1.1.0. (And we >> could tease the forthcoming 2.4 release as building against 1.1.1/TLS 1.3.) > > Good idea. How about this, to insert after the "This release requires > the Apache Portable Runtime (APR)," paragraph? > > """ > This release is compatible with OpenSSL versions from 0.9.8a to > 1.1.0 only, and does not support TLSv1.3. Future releases of httpd 2.4 > are expected to add compatibility with OpenSSL 1.1.1 and enable support > for TLSv1.3. > """ > > Regards, Joe
Re: NOTICE: Intent to T 2.4.35 in the next few hours
On 09/19/2018 12:54 PM, Joe Orton wrote: > On Tue, Sep 18, 2018 at 11:19:10AM -0500, William A Rowe Jr wrote: >> On Tue, Sep 18, 2018 at 2:43 AM Joe Orton wrote: >>> You'll likely see issues testing against OpenSSL 1.1.1 until the TLSv1.3 >>> merge is integrated for 2.4.x, yeah, I wouldn't worry about that. >> >> But I think this is worth highlighting in our Announcement, that we would >> strongly caution users to build 2.4.35 against OpenSSL 1.1.0. (And we >> could tease the forthcoming 2.4 release as building against 1.1.1/TLS 1.3.) > > Good idea. How about this, to insert after the "This release requires > the Apache Portable Runtime (APR)," paragraph? > > """ > This release is compatible with OpenSSL versions from 0.9.8a to > 1.1.0 only, and does not support TLSv1.3. Future releases of httpd 2.4 > are expected to add compatibility with OpenSSL 1.1.1 and enable support > for TLSv1.3. > """ +1 Regards Rüdiger
Re: [VOTE] Release httpd-2.4.35
On Mon, Sep 17, 2018 at 07:56:52PM -0500, Daniel Ruggeri 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.35: > [ ] +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 release, passes tests on Fedora 28 (OpenSSL 1.1.0h), CHANGES looks good. Thanks for RMing, Daniel! Regards, Joe
Re: [VOTE] Release httpd-2.4.35
On 18/09/2018 10:56, Daniel Ruggeri wrote: > Hi, all; > Please find below the proposed release tarball and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ all good on slackware 13.0+ with apr 1.6.5 and apr-util 1.6.1 -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, 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. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument
Re: NOTICE: Intent to T 2.4.35 in the next few hours
On Tue, Sep 18, 2018 at 11:19:10AM -0500, William A Rowe Jr wrote: > On Tue, Sep 18, 2018 at 2:43 AM Joe Orton wrote: > > You'll likely see issues testing against OpenSSL 1.1.1 until the TLSv1.3 > > merge is integrated for 2.4.x, yeah, I wouldn't worry about that. > > But I think this is worth highlighting in our Announcement, that we would > strongly caution users to build 2.4.35 against OpenSSL 1.1.0. (And we > could tease the forthcoming 2.4 release as building against 1.1.1/TLS 1.3.) Good idea. How about this, to insert after the "This release requires the Apache Portable Runtime (APR)," paragraph? """ This release is compatible with OpenSSL versions from 0.9.8a to 1.1.0 only, and does not support TLSv1.3. Future releases of httpd 2.4 are expected to add compatibility with OpenSSL 1.1.1 and enable support for TLSv1.3. """ Regards, Joe
Re: [VOTE] Release httpd-2.4.35
+1 h2 testsuite: - MacOS 10.13 - Ubuntu 16.04.5 LTS (i386) - Ubuntu 16.04.5 LTS (x86_64) md testsuite - MacOS 10.13 Looks good, thanks for RMing! -Stefan > Am 18.09.2018 um 02:56 schrieb Daniel Ruggeri : > > 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.35: > [ ] +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: > md5: 92ddccfbd43b533578499d1faaad17fe *httpd-2.4.35.tar.gz > sha1: b7996c2c1f7ff5bb217114fe5354a19a5207ab62 *httpd-2.4.35.tar.gz > sha256: 31c2c82c9cd34749cbb60d04619d9aa3fb0814ab22246ad588d2426dde90c72c > *httpd-2.4.35.tar.gz > > -- > Daniel Ruggeri >
Re: [VOTE] Release httpd-2.4.35
Apologies, my mistake. Was going down the wrong rabbit hole and ended in a version 0.0.01 off. :-S Stefan > Am 19.09.2018 um 11:05 schrieb Daniel Gruno : > > On 09/19/2018 10:56 AM, Stefan Eissing wrote: >> -1, the tag is not from HEAD of 2.4.x. >> Specifically it seems to me it is missing: >> r1840757 | jim | 2018-09-12 22:38:02 +0200 (Mi, 12 Sep 2018) | 12 lines >> Merge r1840010 from trunk: >> ... >> Can someone confirm that the tag seems to miss changes at the time it was >> done? > > Cannot confirm, the merge is present in the 2.4.35 tag. > Where are you not seeing your changes? > > I checked > http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.35/modules/http2/h2_session.c?view=markup > and the changes are there.. > >> -Stefan >>> Am 18.09.2018 um 02:56 schrieb Daniel Ruggeri : >>> >>> 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.35: >>> [ ] +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: >>> md5: 92ddccfbd43b533578499d1faaad17fe *httpd-2.4.35.tar.gz >>> sha1: b7996c2c1f7ff5bb217114fe5354a19a5207ab62 *httpd-2.4.35.tar.gz >>> sha256: 31c2c82c9cd34749cbb60d04619d9aa3fb0814ab22246ad588d2426dde90c72c >>> *httpd-2.4.35.tar.gz >>> >>> -- >>> Daniel Ruggeri >>> >
Re: [VOTE] Release httpd-2.4.35
On 09/19/2018 10:56 AM, Stefan Eissing wrote: -1, the tag is not from HEAD of 2.4.x. Specifically it seems to me it is missing: r1840757 | jim | 2018-09-12 22:38:02 +0200 (Mi, 12 Sep 2018) | 12 lines Merge r1840010 from trunk: ... Can someone confirm that the tag seems to miss changes at the time it was done? Cannot confirm, the merge is present in the 2.4.35 tag. Where are you not seeing your changes? I checked http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.35/modules/http2/h2_session.c?view=markup and the changes are there.. -Stefan Am 18.09.2018 um 02:56 schrieb Daniel Ruggeri : 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.35: [ ] +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: md5: 92ddccfbd43b533578499d1faaad17fe *httpd-2.4.35.tar.gz sha1: b7996c2c1f7ff5bb217114fe5354a19a5207ab62 *httpd-2.4.35.tar.gz sha256: 31c2c82c9cd34749cbb60d04619d9aa3fb0814ab22246ad588d2426dde90c72c *httpd-2.4.35.tar.gz -- Daniel Ruggeri
Re: [VOTE] Release httpd-2.4.35
-1, the tag is not from HEAD of 2.4.x. Specifically it seems to me it is missing: r1840757 | jim | 2018-09-12 22:38:02 +0200 (Mi, 12 Sep 2018) | 12 lines Merge r1840010 from trunk: ... Can someone confirm that the tag seems to miss changes at the time it was done? -Stefan > Am 18.09.2018 um 02:56 schrieb Daniel Ruggeri : > > 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.35: > [ ] +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: > md5: 92ddccfbd43b533578499d1faaad17fe *httpd-2.4.35.tar.gz > sha1: b7996c2c1f7ff5bb217114fe5354a19a5207ab62 *httpd-2.4.35.tar.gz > sha256: 31c2c82c9cd34749cbb60d04619d9aa3fb0814ab22246ad588d2426dde90c72c > *httpd-2.4.35.tar.gz > > -- > Daniel Ruggeri >
