Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c
No, sorry I am still confused on just which we're talking about here, support/main.c or ab.c (which I was thinking) or both? Looking over this thread on and off list seems to be a merge of both. So because of that; -1 to adding to applink to support/main.c. httpd.exe isn't even linked to ossl. For abs.exe specifically, this all started here: https://www.apachelounge.com/viewtopic.php?t=7134 and continued in PR 59630. I just tested a AH vc14 build of 2.4.20 from 4/2016 and C:\Apache24\bin>abs https://google.com/ OPENSSL_Uplink(7FF8EB479000,08): no OPENSSL_Applink So it was a problem at one time. Today I did a vc14 x64 builds of current abs with the include line for applink commented out for all current ossl versions and none of the three fail. Then I did a 2.4.20 build with ossl 1.0.2p and no error. Next one with 1.0.2p and apr/u 1.5.x (as the 4/2016 build was) and again no fail. Next apr/u 1.5 and ossl 1.0.2g (exact same as the 4/2016 build) and C:\Apache24\bin>abs http://google.com/ OPENSSL_Uplink(7FF900589000,08): no OPENSSL_Applink So Bill as you eluded to somwhere in all the tl;dr in this thread you are correct and openssl was the problem and it does seem fixed now. Spending much of my day on this I've found applink.c began in 0.9.8. I think it's always been in the ms folder and just copied to include(inc32)/openssl during the building process. So knowing all this I'm now +1 on removing the applink include in ab.c. Cheers On 10/13/2018 11:22 AM, William A Rowe Jr wrote: On Sat, Oct 13, 2018 at 12:00 PM Gregg Smith wrote: On 10/13/2018 8:32 AM, William A Rowe Jr wrote: Sorry, I don't understand. Gregg, can you shed some insight here? For both, applink.c is helpful if the OpenSSL .dll files are created with a different VC compiler than abs.exe was compiled with. Not true, OSSL 1.0.2 I know from experience if applink.c is not included it will still err even if both ab.c & OSSL are compiled with the same VC version (14 & 15). I never tested 1.1.0. I can assure you that was not true, having built against 0.9.7, .8, 1.0.0, etc etc etc. What can break is that if you build openssl in a different model (the whole /MD, /MT etc) than abs.c, then yes, they could be disjointed. Can you find me any pointers to the claim that I could investigate further? .exe, it cannot be found from a .dll or Apache .so loadable.module. Otherwise, I understand this to be a noop. No, it just got moved to the ms folder is all that happened at 1.1.0 and is still there in 1.1.1. No, I'm certain that's incorrect. It was always in ms/ in the source bundle and was previously installed into include/openssl/ on applicable platforms. The fact that it isn't in the resulting installed -devel tree suggests it is no longer recommended, or that the openssl maintainers got the refactoring of their build schema wrong. I'm -1 on this till at least the majority of OSSL versions do not include applink.c. I read this as logical converse, you are +1 to patch main.c to include it? This suggests we need to re-raise the issue at the openssl project or declare 1.1.1 incompatible without the workaround of finding the library source bundle, or manually installing applink.c where it used to be.
Re: [VOTE] Release httpd-2.4.36
+1 FreeBSD 11.2-RELEASE-p4 security/openssl111 - 1.1.1_1 Hosting several live sites without errors or issues on this release candidate. TLSv1.3 successfully negotiated for capable browsers. Regards, Dennis
h2 broken in 2.4.36 with OpenSSL 1.1.1? Related to SSL_MODE_AUTO_RETRY?
It seems the h2 failure only happens when building httpd against OpenSSL 1.1.1 (independent of TLS version used). I did a quick check with an httpd build against 1.1.0i and there the same vhost of the test framework instance worked with the same clients, that failed for 1.1.1. The client side OpenSSL version seems not to matter. When using 1.1.1 in the server even browsers seem to fail with h2. Anyone who can successfully use h2 with 2.4.36 build against OpenSSL 1.1.1? When comparing trace logs between the 1.1.1 server and the 1.1.0i server, one can see, that a failing OpenSSL read (0 bytes) results in APR_EOF (70014) for 1.1.1 but in errno 11 (EAGAIN) for 1.1.0i. I wonder whether this is due to the new SSL_MODE_AUTO_RETRY and maybe the following change: +#if OPENSSL_VERSION_NUMBER >= 0x1010100fL +/* For OpenSSL >=1.1.1, disable auto-retry mode so it's possible + * to consume handshake records without blocking for app-data. + * https://github.com/openssl/openssl/issues/7178 */ +SSL_CTX_clear_mode(ctx, SSL_MODE_AUTO_RETRY); +#endif The logs: < OpenSSL 1.1.1 > OpenSSL 1.1.0i < 23:35:16.021201 h2_session.c(1704): AH03078: h2_session(81,BUSY,0): transit [INIT] -- init --> [BUSY] > 23:39:55.715439 h2_session.c(1670): AH03078: h2_session(66,BUSY,0): transit [INIT] -- init --> [BUSY] Some additional early stuff for 1.1.0i > 23:39:55.715448 h2_filter.c(145): h2_session(66): read, NONBLOCK_READ, mode=0, readbytes=65536 > 23:39:55.715470 ssl_engine_io.c(): OpenSSL: I/O error, 5 bytes expected to read on BIO#7efee0005280 [mem: 7efee0014ee3] > 23:39:55.715480 h2_filter.c(190): (11)Resource temporarily unavailable: h2_session(66): read > 23:39:55.715508 h2_mplx.c(1240): h2_mplx(66): dispatch events > 23:39:55.715536 h2_session.c(589): AH03068: h2_session(66,BUSY,0): sent FRAME[SETTINGS[length=6, stream=0]], frames=0/1 (r/s) > 23:39:55.715548 h2_session.c(589): AH03068: h2_session(66,BUSY,0): sent FRAME[WINDOW_UPDATE[stream=0, incr=2147418112]], frames=0/2 (r/s) > 23:39:55.715565 h2_conn_io.c(122): h2_session(66)-out: heap[28] flush > 23:39:55.715590 core_filters.c(580): brigade contains: bytes: 57, non-file bytes: 57, eor buckets: 0, morphing buckets: 0 > 23:39:55.715598 ssl_engine_io.c(2213): OpenSSL: write 57/57 bytes to BIO#7efee00021b0 [mem: 7efee0014ee3] > 23:39:55.715648 core_filters.c(525): will flush because of FLUSH bucket > 23:39:55.715653 core_filters.c(535): seen in brigade so far: bytes: 57, non-file bytes: 57, eor buckets: 0, morphing buckets: 0 > 23:39:55.715657 core_filters.c(554): flushing now > 23:39:55.715683 core_filters.c(569): total bytes written: 2466 > 23:39:55.715690 core_filters.c(580): brigade contains: bytes: 0, non-file bytes: 0, eor buckets: 0, morphing buckets: 0 Then many things identical < 23:35:16.021217 h2_filter.c(145): h2_session(81): read, NONBLOCK_READ, mode=0, readbytes=65536 > 23:39:55.715697 h2_filter.c(145): h2_session(66): read, NONBLOCK_READ, mode=0, readbytes=65536 < 23:35:16.021252 ssl_engine_io.c(2213): OpenSSL: read 5/5 bytes from BIO#7f1d04002b10 [mem: 7f1d040145a3] < 23:35:16.021277 ssl_engine_io.c(2213): OpenSSL: read 41/41 bytes from BIO#7f1d04002b10 [mem: 7f1d040145a8] < 23:35:16.021318 h2_filter.c(93): bb_dump(81): RAW_in(TRANSIENT[24]) < 23:35:16.021340 h2_filter.c(64): h2_session(81,BUSY,0): fed 24 bytes to nghttp2, 24 read > 23:39:55.715713 ssl_engine_io.c(2213): OpenSSL: read 5/5 bytes from BIO#7efee0005280 [mem: 7efee0014ee3] > 23:39:55.715734 ssl_engine_io.c(2213): OpenSSL: read 48/48 bytes from BIO#7efee0005280 [mem: 7efee0014ee8] > 23:39:55.715774 h2_filter.c(93): bb_dump(66): RAW_in(TRANSIENT[24]) > 23:39:55.715786 h2_filter.c(64): h2_session(66,BUSY,0): fed 24 bytes to nghttp2, 24 read < 23:35:16.021355 h2_filter.c(145): h2_session(81): read, NONBLOCK_READ, mode=0, readbytes=65536 < 23:35:16.021364 ssl_engine_io.c(2213): OpenSSL: read 5/5 bytes from BIO#7f1d04002b10 [mem: 7f1d040145a3] < 23:35:16.021384 ssl_engine_io.c(2213): OpenSSL: read 44/44 bytes from BIO#7f1d04002b10 [mem: 7f1d040145a8] < 23:35:16.021428 h2_filter.c(93): bb_dump(81): RAW_in(TRANSIENT[27]) < 23:35:16.021442 h2_session.c(341): AH03066: h2_session(81,BUSY,0): recv FRAME[SETTINGS[length=18, stream=0]], frames=0/0 (r/s) < 23:35:16.021447 h2_session.c(414): h2_session(81,BUSY,0): SETTINGS, len=18 > 23:39:55.715792 h2_filter.c(145): h2_session(66): read, NONBLOCK_READ, mode=0, readbytes=65536 > 23:39:55.715804 ssl_engine_io.c(2213): OpenSSL: read 5/5 bytes from BIO#7efee0005280 [mem: 7efee0014ee3] > 23:39:55.715825 ssl_engine_io.c(2213): OpenSSL: read 51/51 bytes from BIO#7efee0005280 [mem: 7efee0014ee8] > 23:39:55.715897 h2_filter.c(93): bb_dump(66): RAW_in(TRANSIENT[27]) > 23:39:55.715926 h2_session.c(341): AH03066: h2_session(66,BUSY,0): recv FRAME[SETTINGS[length=18, stream=0]], frames=0/2 (r/s) > 23:39:55.715934 h2_session.c(414): h2_session(66,BUSY,0): SETTINGS, len=18 < 23:35:16.021451
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c
On Sat, Oct 13, 2018 at 1:22 PM William A Rowe Jr wrote: > On Sat, Oct 13, 2018 at 12:00 PM Gregg Smith wrote: > >> On 10/13/2018 8:32 AM, William A Rowe Jr wrote: >> > Otherwise, I understand this to be a noop. >> > >> No, it just got moved to the ms folder is all that happened at 1.1.0 and >> is still there in 1.1.1. >> > > No, I'm certain that's incorrect. It was always in ms/ in the source bundle > and was previously installed into include/openssl/ on applicable platforms. > The fact that it isn't in the resulting installed -devel tree suggests it > is no > longer recommended, or that the openssl maintainers got the refactoring > of their build schema wrong. > Just to carve out this single aspect of the discussion, I've logged a ticket with openssl about the absence of include/openssl/applink.c; https://github.com/openssl/openssl/issues/7396
Re: Failing http2.t in 2.4.36 [Was: NOTICE: Intent to T 2.4.36]
Hi Stefan, it is the "input gone" (APR_EOF) case which went unnoticed by me. Although I patch the test suite to run with trace8 log level, http2 was set to debug in the test suite config and the "input gone" message is a trace message. See below for more details. The question is still whether this should have been handled non-fatally. Currently curl fails to do h2 with httpd 2.4.36 as set up by the test suite. Am 13.10.2018 um 18:53 schrieb Stefan Eissing: Hi Rainer, according to the log, the h2 code must be in the H2_SESSION_ST_BUSY state and the only cause I see is the same as you, namely an unexpected status from h2_session_read(), which should come via status = ap_get_brigade(c->input_filters, session->bbtmp, AP_MODE_READBYTES, block? APR_BLOCK_READ : APR_NONBLOCK_READ, H2MAX(APR_BUCKET_BUFF_SIZE, readlen)); block is 0 here and readlen should be (unless reconfigured via H2StreamMaxMemSize) 32kb. Maybe you could just add a log line there to see what ap_get_brigade() returned there? Strange. I hope most of the added http2:debug log lines with logno AH* are self-explaining: ... 22:25:25.934782 [core:trace8] core_filters.c(554): [client 127.0.0.1:36318] flushing now 22:25:25.934810 [core:trace8] core_filters.c(569): [client 127.0.0.1:36318] total bytes written: 3197 22:25:25.934816 [core:trace8] core_filters.c(580): [client 127.0.0.1:36318] brigade contains: bytes: 0, non-file bytes: 0, eor buckets: 0, morphing buckets: 0 22:25:25.934823 [http2:debug] h2_session.c(1552): [client 127.0.0.1:36318] AH7: h2_session(75,BUSY,1): Into session_read non-blocking readlen 65536 read_start 103 22:25:25.934828 [http2:trace1] h2_filter.c(145): [client 127.0.0.1:36318] h2_session(75): read, NONBLOCK_READ, mode=0, readbytes=65536 22:25:25.934878 [ssl:trace4] ssl_engine_io.c(2213): [client 127.0.0.1:36318] OpenSSL: read 0/5 bytes from BIO#7ff098002b10 [mem: 7ff0980164d3] (BIO dump follows) 22:25:25.934894 [ssl:trace7] ssl_engine_io.c(2136): [client 127.0.0.1:36318] +-+ 22:25:25.934898 [ssl:trace7] ssl_engine_io.c(2180): [client 127.0.0.1:36318] +-+ 22:25:25.934903 [http2:trace1] h2_filter.c(190): (70014)End of file found: [client 127.0.0.1:36318] h2_session(75): read 22:25:25.934908 [http2:debug] h2_session.c(1563): (70014)End of file found: [client 127.0.0.1:36318] AH0: h2_session(75,BUSY,1): session_read non-blocking readlen 65536 ap_get_brigade returned status 70014 22:25:25.934913 [http2:debug] h2_session.c(1603): (70014)End of file found: [client 127.0.0.1:36318] AH8: h2_session(75,BUSY,1): input gone 22:25:25.934917 [http2:trace1] h2_session.c(1605): (70014)End of file found: [client 127.0.0.1:36318] h2_session(75,BUSY,1): input gone 22:25:25.934921 [http2:debug] h2_session.c(1616): [client 127.0.0.1:36318] AH4: h2_session(75,BUSY,1): session_read non-blocking readlen 65536 status 70014 (default case) session->io.bytes_read == read_start (103 == 103) returning status 70014 22:25:25.934926 [http2:debug] h2_session.c(1645): (70014)End of file found: [client 127.0.0.1:36318] AH9: h2_session(75,BUSY,1): h2_session_read non-blocking returning 70014 22:25:25.934931 [http2:debug] h2_session.c(1794): [client 127.0.0.1:36318] AH03401: h2_session(75,BUSY,1): conn error -> shutdown 22:25:25.934938 [http2:debug] h2_session.c(589): [client 127.0.0.1:36318] AH03068: h2_session(75,BUSY,1): sent FRAME[GOAWAY[error=0, reason='', last_stream=1]], frames=3/4 (r/s) I reduced my long list of loaded modules to check, whether a filter in some module interacts badly, but the problem still happens with the following modules loaded: mod_mpm_event.so mod_authn_file.so mod_authn_anon.so mod_authn_socache.so mod_authn_core.so mod_authz_host.so mod_authz_groupfile.so mod_authz_user.so mod_authz_owner.so mod_authz_core.so mod_access_compat.so mod_auth_basic.so mod_allowmethods.so mod_socache_shmcb.so mod_watchdog.so mod_macro.so mod_reqtimeout.so mod_filter.so mod_mime.so mod_log_debug.so mod_env.so mod_headers.so mod_unique_id.so mod_setenvif.so mod_version.so mod_remoteip.so mod_slotmem_shm.so mod_slotmem_plain.so mod_ssl.so mod_http2.so mod_unixd.so mod_heartbeat.so mod_heartmonitor.so mod_status.so mod_info.so mod_cgid.so mod_cgi.so mod_dir.so mod_alias.so mod_rewrite.so and the usual test modules: mod_eat_post.so mod_input_body_filter.so mod_test_pass_brigade.so mod_echo_post.so mod_nntp_like.so mod_fold.so mod_client_add_filter.so mod_memory_track.so mod_test_ssl.so mod_test_apr_uri.so mod_list_modules.so mod_random_chunk.so mod_authany.so mod_test_utilities.so mod_echo_post_chunk.so mod_test_rwrite.so mod_mime.so mod_alias.so I don't know how to correctly distinguish a real
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c
On Sat, Oct 13, 2018 at 2:06 PM Ivan Zhakov wrote: > On Sat, 13 Oct 2018 at 20:00, Gregg Smith wrote: > >> On 10/13/2018 8:32 AM, William A Rowe Jr wrote: >> > Sorry, I don't understand. >> > >> > Gregg, can you shed some insight here? For both, applink.c is helpful if >> > the OpenSSL .dll files are created with a different VC compiler than >> > abs.exe was compiled with. >> >> Not true, OSSL 1.0.2 I know from experience if applink.c is not included >> it will still err even if both ab.c & OSSL are compiled with the same VC >> version (14 & 15). I never tested 1.1.0. >> >> That's true: since OpenSSL 1.0.2 applink.c is required even if OpenSSL и > application uses same VC toolchain. > That's very interesting, not observed here. Second request... pointers please? I'm strongly suspecting an /MD /MT mismatch. I only build the 'ntdll' style of OpenSSL, and never bother to mix linkage models or build abs.c static against openssl etc. Or perhaps this speaks to specific, buggy releases of 1.0.2? [Something for the audience; applink.c redirects all of the "standard c library" API's used by OpenSSL into the flavor in use by the version of the MSVC runtime linked to the primary .exe file. And in it's absence, the flavor OpenSSL was built against. Why we almost never care? These apply to basic input/output, the BIO layer of OpenSSL, which mod_ssl hardly touches. But apps using classic C stdio functionality like ab.c care a great deal. Which leads us to Ivan's comment;] > Alternative solution to including applink.c could stop using OpenSSL APIs > that uses stdio and provide APR based BIO implementation. In this case > OpenSSL will never use stdio functions. > Indeed! That's a complete solution. But a lot of effort if Boring/Libre/etc "just work" and only OpenSSL falls down on doing the simplest BIO functions. I'd have to fault OpenSSL, and not promote workarounds. Again I need some citations about the "defect" which makes zero sense here. It would also support building mod_ssl with OpenSSL compiled with option > --no-stdio. > Indeed, I'm shocked if we can't build mod_ssl with --no-stdio today! Those would be some odd quirks in mod_ssl/openssl (discounting ab.c)... but that's certainly another thread. It seems like a worthwhile goal, nothing should speak stdio within mod_ssl's structure.
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c
On Sat, 13 Oct 2018 at 20:00, Gregg Smith wrote: > On 10/13/2018 8:32 AM, William A Rowe Jr wrote: > > Sorry, I don't understand. > > > > Gregg, can you shed some insight here? For both, applink.c is helpful if > > the OpenSSL .dll files are created with a different VC compiler than > > abs.exe was compiled with. > > Not true, OSSL 1.0.2 I know from experience if applink.c is not included > it will still err even if both ab.c & OSSL are compiled with the same VC > version (14 & 15). I never tested 1.1.0. > > That's true: since OpenSSL 1.0.2 applink.c is required even if OpenSSL и application uses same VC toolchain. Alternative solution to including applink.c could stop using OpenSSL APIs that uses stdio and provide APR based BIO implementation. In this case OpenSSL will never use stdio functions. It would also support building mod_ssl with OpenSSL compiled with option --no-stdio. -- Ivan Zhakov
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
On Sat, Oct 13, 2018 at 1:35 PM William A Rowe Jr
wrote:
> On Wed, Oct 10, 2018 at 12:27 PM wrote:
>
>> Author: jim
>> Date: Wed Oct 10 17:27:33 2018
>> New Revision: 1843478
>>
>> URL: http://svn.apache.org/viewvc?rev=1843478=rev
>> Log:
>> Better method... just check return status
>>
>> Modified:
>> httpd/test/framework/trunk/t/ssl/ocsp.t
>>
>> Modified: httpd/test/framework/trunk/t/ssl/ocsp.t
>> URL:
>> http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/ssl/ocsp.t?rev=1843478=1843477=1843478=diff
>>
>> ==
>> --- httpd/test/framework/trunk/t/ssl/ocsp.t (original)
>> +++ httpd/test/framework/trunk/t/ssl/ocsp.t Wed Oct 10 17:27:33 2018
>> @@ -21,7 +21,7 @@ Apache::TestRequest::module('ssl_ocsp');
>> # support in earlier versions without messing around with stderr
>> my $openssl = Apache::TestSSLCA::openssl();
>> if (!have_min_apache_version('2.4.26')
>> -or `$openssl list-standard-commands 2>/dev/null` !~ /ocsp/) {
>> +or system("$openssl ocsp 2>/dev/null") == 0) {
>>
>
> On Windows, /dev/null is invalid (output target nul, eg NUL).
>
> On every platform this is an always-fail noop, since `openssl ocsp` always
> results in an error. Not enough arguments. You disabled this test on all
> environments, please revert.
>
> One test without extraneous stdout garbage might be to test ( `$openssl
> ocsp -help` !~ /Usage:/ ) ... in theory this would both succeed (success
> 0), eat stdout, and there should be no Usage: instructions if the ocsp verb
> doesn't exist.
>
e.g.
$ openssl xyz -help
Invalid command 'xyz'; type "help" for a list.
$ echo $?
1
$ openssl ocsp -help
Usage: ocsp [options]
Valid options are:
-help Display this summary
-out outfileOutput filename
[...]
$ echo $?
0
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
On Wed, Oct 10, 2018 at 12:27 PM wrote:
> Author: jim
> Date: Wed Oct 10 17:27:33 2018
> New Revision: 1843478
>
> URL: http://svn.apache.org/viewvc?rev=1843478=rev
> Log:
> Better method... just check return status
>
> Modified:
> httpd/test/framework/trunk/t/ssl/ocsp.t
>
> Modified: httpd/test/framework/trunk/t/ssl/ocsp.t
> URL:
> http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/ssl/ocsp.t?rev=1843478=1843477=1843478=diff
>
> ==
> --- httpd/test/framework/trunk/t/ssl/ocsp.t (original)
> +++ httpd/test/framework/trunk/t/ssl/ocsp.t Wed Oct 10 17:27:33 2018
> @@ -21,7 +21,7 @@ Apache::TestRequest::module('ssl_ocsp');
> # support in earlier versions without messing around with stderr
> my $openssl = Apache::TestSSLCA::openssl();
> if (!have_min_apache_version('2.4.26')
> -or `$openssl list-standard-commands 2>/dev/null` !~ /ocsp/) {
> +or system("$openssl ocsp 2>/dev/null") == 0) {
>
On Windows, /dev/null is invalid (output target nul, eg NUL).
On every platform this is an always-fail noop, since `openssl ocsp` always
results in an error. Not enough arguments. You disabled this test on all
environments, please revert.
One test without extraneous stdout garbage might be to test ( `$openssl
ocsp -help` !~ /Usage:/ ) ... in theory this would both succeed (success
0), eat stdout, and there should be no Usage: instructions if the ocsp verb
doesn't exist.
Thoughts?
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c
On Sat, Oct 13, 2018 at 12:00 PM Gregg Smith wrote: > On 10/13/2018 8:32 AM, William A Rowe Jr wrote: > > Sorry, I don't understand. > > > > Gregg, can you shed some insight here? For both, applink.c is helpful if > > the OpenSSL .dll files are created with a different VC compiler than > > abs.exe was compiled with. > > Not true, OSSL 1.0.2 I know from experience if applink.c is not included > it will still err even if both ab.c & OSSL are compiled with the same VC > version (14 & 15). I never tested 1.1.0. > I can assure you that was not true, having built against 0.9.7, .8, 1.0.0, etc etc etc. What can break is that if you build openssl in a different model (the whole /MD, /MT etc) than abs.c, then yes, they could be disjointed. Can you find me any pointers to the claim that I could investigate further? > .exe, it cannot be found from a .dll or Apache .so loadable.module. > > Otherwise, I understand this to be a noop. > > No, it just got moved to the ms folder is all that happened at 1.1.0 and > is still there in 1.1.1. > No, I'm certain that's incorrect. It was always in ms/ in the source bundle and was previously installed into include/openssl/ on applicable platforms. The fact that it isn't in the resulting installed -devel tree suggests it is no longer recommended, or that the openssl maintainers got the refactoring of their build schema wrong. > I'm -1 on this till at least the majority of OSSL versions do not > include applink.c. > I read this as logical converse, you are +1 to patch main.c to include it? This suggests we need to re-raise the issue at the openssl project or declare 1.1.1 incompatible without the workaround of finding the library source bundle, or manually installing applink.c where it used to be.
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c
On 10/13/2018 8:32 AM, William A Rowe Jr wrote: Sorry, I don't understand. Gregg, can you shed some insight here? For both, applink.c is helpful if the OpenSSL .dll files are created with a different VC compiler than abs.exe was compiled with. Not true, OSSL 1.0.2 I know from experience if applink.c is not included it will still err even if both ab.c & OSSL are compiled with the same VC version (14 & 15). I never tested 1.1.0. .exe, it cannot be found from a .dll or Apache .so loadable.module. Otherwise, I understand this to be a noop. No, it just got moved to the ms folder is all that happened at 1.1.0 and is still there in 1.1.1. I'm -1 on this till at least the majority of OSSL versions do not include applink.c. OpenSSL project deprecated, that is, no longer ships applink.c in include/openssl/ install directory. LibreSSL and BoringSSL have no such resource. Since you indicate that patching is trivial, and building with two different compilers isn't something an open source project should fret about, the Apache.exe and abs.exe should behave the same way. Pick one. On Sat, Oct 13, 2018, 04:04 Steffen wrote: Do not understand your writing. abs.exe needs the applink shim, so leave it in. Op 12 okt. 2018 om 23:54 heeft William A Rowe Jr het volgende geschreven: Great, I'll proceed with changing ab.c to remove the hack, since it is unneeded when ab.c is compiled by the same toolchain as libcrypto.dll, isn't available in non-openssl distributions, and was deprecated in 1.1.1 again. Anyone interested can proceed to patch both and provision applink.c when working with OpenSSL 1.1.1, so I don't need to raise a ticket that project On Fri, Oct 12, 2018, 16:37 Steffen wrote: Already for years we have in server/main.c : #include "applink.c" This solves errors like: no OPENSSL_Applink , see for example : https://www.apachelounge.com/viewtopic.php?p=30986 No problem to patch. Op 12 okt. 2018 om 22:03 heeft William A Rowe Jr het volgende geschreven: ... and still hanging. Rather than ApacheLounge and some others needing to patch each time, did we conclude that we should wire in the applink.c stub into Apache.exe as shipped by httpd project? (I've never mixed binaries of different MSVC environments, so myself, I don't care, but it seems to raise issues for a subset of the community.) On Mon, Sep 17, 2018 at 7:05 PM William A Rowe Jr wrote: So we kind of left this hanging... On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith wrote: On 6/15/2016 9:20 AM, William A Rowe Jr wrote: In building httpd.exe, some users don't build and install openssl. It isn't going to be possible to simply #include without some conditional test. OpenSSL itself is partly the culprit, for not having an APPLINK_REQUIRED style macro conditional. But we can work around this in the cmake tests. This is why the patch creator put this inside a HAVE_OPENSSL block so ab.exe did not get this added. abs (at least on the dsp et. al.) is not built unless there is OpenSSL present. I'll look at making this a standard bit of the httpd 2.4 build. We can likely add a user-toggled flag to the os/win32/os.h? Seems to me this is not needed . So, is the win32 community in favor of using HAVE_OPENSSL to include applink.c in the scope of main.c (as revised in the current ab.c sources, to avoid this on libressl?) There is a presumption that the crt used by libhttpd the same as libapr, but I think this is a reasonable connection. The entire logic to main.c should be as simple as... #if defined(HAVE_OPENSSL) && defined(_MSC_VER) && !defined(LIBRESSL_VERSION_NUMBER) /* The following logic ensures we correctly glue FILE* within one CRT used * by the OpenSSL library build to another CRT used by the ab.exe build. * This became especially problematic with Visual Studio 2015. */ #include #endif By inserting the structure in httpd.exe, that structure can be found by the openssl library, which is not true of including this in a loadable library such as libhttpd.dll or libaprutil-1.dll.
Re: Failing http2.t in 2.4.36 [Was: NOTICE: Intent to T 2.4.36]
Hi Rainer,
according to the log, the h2 code must be in the H2_SESSION_ST_BUSY state and
the only cause I see is the same as you, namely an unexpected status from
h2_session_read(), which should come via
status = ap_get_brigade(c->input_filters,
session->bbtmp, AP_MODE_READBYTES,
block? APR_BLOCK_READ : APR_NONBLOCK_READ,
H2MAX(APR_BUCKET_BUFF_SIZE, readlen));
block is 0 here and readlen should be (unless reconfigured via
H2StreamMaxMemSize) 32kb.
Maybe you could just add a log line there to see what ap_get_brigade() returned
there?
Strange.
-Stefan
> Am 13.10.2018 um 13:14 schrieb Rainer Jung :
>
> Hi Stefan,
>
> Am 10.10.2018 um 16:04 schrieb Stefan Eissing:
>>> Am 10.10.2018 um 15:06 schrieb Joe Orton :
>>>
>>> I believe that t/modules/http2.t is dying in this:
>>>
>>>my $old_ref = \&{ 'AnyEvent::TLS::_get_session' };
>>>*{ 'AnyEvent::TLS::_get_session' } = sub($$;$$) {
>>>
>>> piece of magic which I don't understand but possibly needs updating for
>>> TLSv1.3? Session handling is different now... everything is broken.
>> I think there was no official way to add SNI to AnyEvent and I had to hack
>> this. Unless anyone has another suggestion, I am in favour of removing the
>> t/modules/http2.t again.
>
> Note that if I manually send http2 requests using a recent curl, I get
> failures as well (for 2.4.36).
>
> The t/modules/http2.t indeed fails for each https test, even the simple first
> one retrieving / and checking for status 200. One bug seems to me in the test
> script, that it fails silently and simply notes that not all tests have run
> at the end.
>
> But if I only start the server using "t/TEST -start-httpd" and then run a
> curl test request against the h2 port 8557, I get failures as well. The
> server was build with TLS 1.3 support, but the failures occur with an 1.3
> client but also with an 1.2 client (different builds of curl). I marked below
> lines probably indicating the failure with .
>
> Here are details:
>
> curl TLS 1.3 client output
> ==
>
> * Trying 127.0.0.1...
> * TCP_NODELAY set
> * Connected to localhost (127.0.0.1) port 8557 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> * TLSv1.3 (IN), TLS handshake, Server hello (2):
> * TLSv1.3 (IN), TLS handshake, [no content] (0):
> * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
> * TLSv1.3 (IN), TLS handshake, [no content] (0):
> * TLSv1.3 (IN), TLS handshake, Certificate (11):
> * TLSv1.3 (IN), TLS handshake, [no content] (0):
> * TLSv1.3 (IN), TLS handshake, CERT verify (15):
> * TLSv1.3 (IN), TLS handshake, [no content] (0):
> * TLSv1.3 (IN), TLS handshake, Finished (20):
> * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
> * TLSv1.3 (OUT), TLS handshake, [no content] (0):
> * TLSv1.3 (OUT), TLS handshake, Finished (20):
> * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
> * ALPN, server accepted to use h2
> * Server certificate:
> * subject: C=US; ST=California; L=San Francisco; O=ASF;
> OU=httpd-test/rsa-test; CN=localhost; emailAddress=test-...@httpd.apache.org
> * start date: Oct 13 08:40:49 2018 GMT
> * expire date: Oct 13 08:40:49 2019 GMT
> * issuer: C=US; ST=California; L=San Francisco; O=ASF; OU=httpd-test; CN=ca;
> emailAddress=test-...@httpd.apache.org
> * SSL certificate verify result: self signed certificate in certificate
> chain (19), continuing anyway.
> * Using HTTP2, server supports multi-use
> * Connection state changed (HTTP/2 confirmed)
> * Copying HTTP/2 data in stream buffer to connection buffer after upgrade:
> len=0
> * TLSv1.3 (OUT), TLS app data, [no content] (0):
> * TLSv1.3 (OUT), TLS app data, [no content] (0):
> * TLSv1.3 (OUT), TLS app data, [no content] (0):
> * Using Stream ID: 1 (easy handle 0x26ab080)
> * TLSv1.3 (OUT), TLS app data, [no content] (0):
> > GET / HTTP/2
> > Host: localhost:8557
> > User-Agent: curl/7.61.1
> > Accept: */*
> >
> * TLSv1.3 (IN), TLS handshake, [no content] (0):
> * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
> * TLSv1.3 (IN), TLS handshake, [no content] (0):
> * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
> * TLSv1.3 (IN), TLS app data, [no content] (0):
> * Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
> * TLSv1.3 (OUT), TLS app data, [no content] (0):
> * TLSv1.3 (IN), TLS app data, [no content] (0):
> * TLSv1.3 (IN), TLS alert, [no content] (0):
> * TLSv1.3 (IN), TLS alert, close notify (256):
> * Empty reply from server
> ^
> * Connection #0 to host localhost left intact
> curl: (52) Empty reply from server
>
> curl TLS 1.3 server error log
> =
>
> 12:37:23.974210 [example_hooks:notice] x_create_connection()
> 12:37:23.974598 [ssl:info] AH01964: Connection to child 66 established
> (server localhost:8557)
>
Re: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c
Sorry, I don't understand. Gregg, can you shed some insight here? For both, applink.c is helpful if the OpenSSL .dll files are created with a different VC compiler than abs.exe was compiled with. And it is only effective if compiled into the .exe, it cannot be found from a .dll or Apache .so loadable.module. Otherwise, I understand this to be a noop. OpenSSL project deprecated, that is, no longer ships applink.c in include/openssl/ install directory. LibreSSL and BoringSSL have no such resource. Since you indicate that patching is trivial, and building with two different compilers isn't something an open source project should fret about, the Apache.exe and abs.exe should behave the same way. Pick one. On Sat, Oct 13, 2018, 04:04 Steffen wrote: > Do not understand your writing. > > abs.exe needs the applink shim, so leave it in. > > > Op 12 okt. 2018 om 23:54 heeft William A Rowe Jr > het volgende geschreven: > > Great, I'll proceed with changing ab.c to remove the hack, since it is > unneeded when ab.c is compiled by the same toolchain as libcrypto.dll, > isn't available in non-openssl distributions, and was deprecated in 1.1.1 > again. > > Anyone interested can proceed to patch both and provision applink.c when > working with OpenSSL 1.1.1, so I don't need to raise a ticket that project > > > On Fri, Oct 12, 2018, 16:37 Steffen wrote: > >> Already for years we have in server/main.c : >> >> #include "applink.c" >> >> >> This solves errors like: no OPENSSL_Applink , see for example : >> https://www.apachelounge.com/viewtopic.php?p=30986 >> >> No problem to patch. >> >> Op 12 okt. 2018 om 22:03 heeft William A Rowe Jr >> het volgende geschreven: >> >> ... and still hanging. >> >> Rather than ApacheLounge and some others needing to patch each time, >> did we conclude that we should wire in the applink.c stub into Apache.exe >> as shipped by httpd project? >> >> (I've never mixed binaries of different MSVC environments, so myself, >> I don't care, but it seems to raise issues for a subset of the community.) >> >> >> On Mon, Sep 17, 2018 at 7:05 PM William A Rowe Jr >> wrote: >> >>> So we kind of left this hanging... >>> >>> On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith wrote: >>> On 6/15/2016 9:20 AM, William A Rowe Jr wrote: > In building httpd.exe, some users don't build and install openssl. It isn't > going > to be possible to simply #include without some > conditional > test. OpenSSL itself is partly the culprit, for not having an > APPLINK_REQUIRED > style macro conditional. But we can work around this in the cmake tests. > This is why the patch creator put this inside a HAVE_OPENSSL block so ab.exe did not get this added. abs (at least on the dsp et. al.) is not built unless there is OpenSSL present. > I'll look at making this a standard bit of the httpd 2.4 build. We can > likely > add a user-toggled flag to the os/win32/os.h? Seems to me this is not needed . >>> >>> So, is the win32 community in favor of using HAVE_OPENSSL to include >>> applink.c in the scope of main.c (as revised in the current ab.c sources, >>> to avoid this on libressl?) >>> >>> There is a presumption that the crt used by libhttpd the same as libapr, >>> but I think this is a reasonable connection. >>> >>> The entire logic to main.c should be as simple as... >>> >>> #if defined(HAVE_OPENSSL) && defined(_MSC_VER) && >>> !defined(LIBRESSL_VERSION_NUMBER) >>> /* The following logic ensures we correctly glue FILE* within one CRT >>> used >>> * by the OpenSSL library build to another CRT used by the ab.exe build. >>> * This became especially problematic with Visual Studio 2015. >>> */ >>> #include >>> #endif >>> >>> By inserting the structure in httpd.exe, that structure can be found by >>> the openssl library, which is not true of including this in a loadable >>> library such as libhttpd.dll or libaprutil-1.dll. >>> >>
Re: Failing http2.t in 2.4.36 [Was: NOTICE: Intent to T 2.4.36]
Adding another debug snippet at the end ...
Am 13.10.2018 um 13:14 schrieb Rainer Jung:
Hi Stefan,
Am 10.10.2018 um 16:04 schrieb Stefan Eissing:
Am 10.10.2018 um 15:06 schrieb Joe Orton :
I believe that t/modules/http2.t is dying in this:
my $old_ref = \&{ 'AnyEvent::TLS::_get_session' };
*{ 'AnyEvent::TLS::_get_session' } = sub($$;$$) {
piece of magic which I don't understand but possibly needs updating for
TLSv1.3? Session handling is different now... everything is broken.
I think there was no official way to add SNI to AnyEvent and I had to
hack this. Unless anyone has another suggestion, I am in favour of
removing the t/modules/http2.t again.
Note that if I manually send http2 requests using a recent curl, I get
failures as well (for 2.4.36).
The t/modules/http2.t indeed fails for each https test, even the simple
first one retrieving / and checking for status 200. One bug seems to me
in the test script, that it fails silently and simply notes that not all
tests have run at the end.
But if I only start the server using "t/TEST -start-httpd" and then run
a curl test request against the h2 port 8557, I get failures as well.
The server was build with TLS 1.3 support, but the failures occur with
an 1.3 client but also with an 1.2 client (different builds of curl). I
marked below lines probably indicating the failure with .
Here are details:
curl TLS 1.3 client output
==
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8557 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=ASF;
OU=httpd-test/rsa-test; CN=localhost;
emailAddress=test-...@httpd.apache.org
* start date: Oct 13 08:40:49 2018 GMT
* expire date: Oct 13 08:40:49 2019 GMT
* issuer: C=US; ST=California; L=San Francisco; O=ASF; OU=httpd-test;
CN=ca; emailAddress=test-...@httpd.apache.org
* SSL certificate verify result: self signed certificate in certificate
chain (19), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after
upgrade: len=0
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* Using Stream ID: 1 (easy handle 0x26ab080)
* TLSv1.3 (OUT), TLS app data, [no content] (0):
> GET / HTTP/2
> Host: localhost:8557
> User-Agent: curl/7.61.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS alert, [no content] (0):
* TLSv1.3 (IN), TLS alert, close notify (256):
* Empty reply from server
^
* Connection #0 to host localhost left intact
curl: (52) Empty reply from server
curl TLS 1.3 server error log
=
12:37:23.974210 [example_hooks:notice] x_create_connection()
12:37:23.974598 [ssl:info] AH01964: Connection to child 66 established
(server localhost:8557)
12:37:23.974726 [ssl:trace2] ssl_engine_rand.c(126): Server: Seeding
PRNG with 144 bytes of entropy
12:37:23.974787 [ssl:trace6] ssl_engine_io.c(2077): Enabling
non-blocking writes
12:37:23.974817 [ssl:trace3] ssl_engine_kernel.c(2191): OpenSSL:
Handshake: start
12:37:23.974860 [ssl:trace3] ssl_engine_kernel.c(2200): OpenSSL: Loop:
before SSL initialization
12:37:23.974886 [ssl:trace4] ssl_engine_io.c(2213): OpenSSL: read 5/5
bytes from BIO#7fe690002b00 [mem: 7fe6900083c3] (BIO dump follows)
12:37:23.974917 [ssl:trace4] ssl_engine_io.c(2213): OpenSSL: read
512/512 bytes from BIO#7fe690002b00 [mem: 7fe6900083c8] (BIO dump follows)
12:37:23.975115 [ssl:trace3] ssl_engine_kernel.c(2200): OpenSSL: Loop:
before SSL initialization
12:37:23.975181 [ssl:debug] ssl_engine_kernel.c(2328): AH02043: SSL
virtual host for
Failing http2.t in 2.4.36 [Was: NOTICE: Intent to T 2.4.36]
Hi Stefan,
Am 10.10.2018 um 16:04 schrieb Stefan Eissing:
Am 10.10.2018 um 15:06 schrieb Joe Orton :
I believe that t/modules/http2.t is dying in this:
my $old_ref = \&{ 'AnyEvent::TLS::_get_session' };
*{ 'AnyEvent::TLS::_get_session' } = sub($$;$$) {
piece of magic which I don't understand but possibly needs updating for
TLSv1.3? Session handling is different now... everything is broken.
I think there was no official way to add SNI to AnyEvent and I had to hack
this. Unless anyone has another suggestion, I am in favour of removing the
t/modules/http2.t again.
Note that if I manually send http2 requests using a recent curl, I get
failures as well (for 2.4.36).
The t/modules/http2.t indeed fails for each https test, even the simple
first one retrieving / and checking for status 200. One bug seems to me
in the test script, that it fails silently and simply notes that not all
tests have run at the end.
But if I only start the server using "t/TEST -start-httpd" and then run
a curl test request against the h2 port 8557, I get failures as well.
The server was build with TLS 1.3 support, but the failures occur with
an 1.3 client but also with an 1.2 client (different builds of curl). I
marked below lines probably indicating the failure with .
Here are details:
curl TLS 1.3 client output
==
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8557 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=ASF;
OU=httpd-test/rsa-test; CN=localhost; emailAddress=test-...@httpd.apache.org
* start date: Oct 13 08:40:49 2018 GMT
* expire date: Oct 13 08:40:49 2019 GMT
* issuer: C=US; ST=California; L=San Francisco; O=ASF; OU=httpd-test;
CN=ca; emailAddress=test-...@httpd.apache.org
* SSL certificate verify result: self signed certificate in certificate
chain (19), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after
upgrade: len=0
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* Using Stream ID: 1 (easy handle 0x26ab080)
* TLSv1.3 (OUT), TLS app data, [no content] (0):
> GET / HTTP/2
> Host: localhost:8557
> User-Agent: curl/7.61.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
* TLSv1.3 (OUT), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS app data, [no content] (0):
* TLSv1.3 (IN), TLS alert, [no content] (0):
* TLSv1.3 (IN), TLS alert, close notify (256):
* Empty reply from server
^
* Connection #0 to host localhost left intact
curl: (52) Empty reply from server
curl TLS 1.3 server error log
=
12:37:23.974210 [example_hooks:notice] x_create_connection()
12:37:23.974598 [ssl:info] AH01964: Connection to child 66 established
(server localhost:8557)
12:37:23.974726 [ssl:trace2] ssl_engine_rand.c(126): Server: Seeding
PRNG with 144 bytes of entropy
12:37:23.974787 [ssl:trace6] ssl_engine_io.c(2077): Enabling
non-blocking writes
12:37:23.974817 [ssl:trace3] ssl_engine_kernel.c(2191): OpenSSL:
Handshake: start
12:37:23.974860 [ssl:trace3] ssl_engine_kernel.c(2200): OpenSSL: Loop:
before SSL initialization
12:37:23.974886 [ssl:trace4] ssl_engine_io.c(2213): OpenSSL: read 5/5
bytes from BIO#7fe690002b00 [mem: 7fe6900083c3] (BIO dump follows)
12:37:23.974917 [ssl:trace4] ssl_engine_io.c(2213): OpenSSL: read
512/512 bytes from BIO#7fe690002b00 [mem: 7fe6900083c8] (BIO dump follows)
12:37:23.975115 [ssl:trace3] ssl_engine_kernel.c(2200): OpenSSL: Loop:
before SSL initialization
12:37:23.975181 [ssl:debug] ssl_engine_kernel.c(2328): AH02043: SSL
virtual host for servername localhost found
12:37:23.975202 [ssl:debug] ssl_engine_kernel.c(2328): AH02043: SSL
Re: [VOTE] Release httpd-2.4.36
Am 11.10.2018 um 20:55 schrieb Ruediger Pluem: On 10/11/2018 08:10 PM, Christophe JAILLET wrote: No issue on my Ubuntu 18.04 VM. On what configuration are you running your tests, Rüdiger? macOS, just like Jim? Centos 7.5 64 Bit Regards Rüdiger The test fails for me as well for 2.4.36 on SLES12. Small bodies are OK, large not. The limit is somewhere between 1.3 and 1.5 MB, not always the same. The test hangs there until mod_reqtimeout times out after a minute, complaining that it could not read more data from the client. If I reduce the multiplicator 100 to eg. 20 it always passes. If I start the test server using "t/TEST -start-httpd" and then use curl to POST data, I can even POST much bigger data and get the correct result back. I use curl -v --data-binary @BIGFILE http://localhost:8529/apache/buffer_in/ > response-body So I assume it is a problem of interaction between the server reading the POST body and the client sending it. My test framework was freshly assembled recently, so lots of current modules. The setup is based on OpenSSL 1.1.1 in the server and in the test framework, but the actual test runs over http, so I don't expect any OpenSSL related reason for the failure. Regards, Rainer Le 11/10/2018 à 13:35, Jim Jagielski a écrit : FWIW, on macOS, both trunk and httpd-2.4 fail on this test: t/modules/buffer.t .. 3/12 # Failed test 4 in t/modules/buffer.t at line 32 t/modules/buffer.t .. 7/12 # Failed test 8 in t/modules/buffer.t at line 32 fail #2 t/modules/buffer.t .. 11/12 # Failed test 12 in t/modules/buffer.t at line 32 fail #3 t/modules/buffer.t .. Failed 3/12 subtests On Oct 11, 2018, at 7:15 AM, Plüm, Rüdiger, Vodafone Group wrote: Do you know if the failure is a regression over 2.4.35? Regards Rüdiger Von: Marion et Christophe JAILLET Gesendet: Donnerstag, 11. Oktober 2018 13:13 An: dev@httpd.apache.org Betreff: re: AW: [VOTE] Release httpd-2.4.36 Waouh! This would mean I've provided a new useful test! (it has been added recently in r1841508) :) I definitely need to document how to generate and use test-coverage data when running the test framework. This helps to spot where new tests are needed. CJ Message du 11/10/18 10:08 De : "Plüm, Rüdiger, Vodafone Group" A : "dev@httpd.apache.org" Copie à : Objet : AW: [VOTE] Release httpd-2.4.36 Anyone else seeing t/modules/buffer.t (Wstat: 0 Tests: 12 Failed: 2) Failed tests: 8, 12 ? I don't see this with trunk on the same machine. Issue seems to be if input filtering is on on large POSTs. Regards Rüdiger
