Re: Current trunk does not build on Win
> But why is this an issue? grep -r output_pending in 2.4.x branch > in modules/... and server/... shows me nothing. No problem with > an MMN major change on 2.5 branch. Ah good point. -- Eric Covener cove...@gmail.com
Re: ab issues (just on macOS?)
What I did was force the ab from the test framework to bind itself to 127.0.0.1 and all is now working OK. > On Apr 10, 2018, at 1:33 PM, Joe Orton wrote: > > On Tue, Apr 10, 2018 at 08:47:03AM -0400, Jim Jagielski wrote: >> My understanding is that this patch was specifically designed >> to address this exact situation, so I am confused why it >> seems to be causing the problem... It's like ab tries ::1, >> doesn't connect and then fails immediately instead of >> then trying 127.0.0.1... > > Can you run ab under something strace-like to see what it's trying to > do? > > Since the test suite defaults to v4-only, possibly we should switch the > test suite to run against http://127.0.0.1:N/ rather than relying on > localhost resolving properly, though exposing these bugs is a good > thing. > > Regardsm Joe
Re: ab issues (just on macOS?)
On Tue, Apr 10, 2018 at 08:47:03AM -0400, Jim Jagielski wrote: > My understanding is that this patch was specifically designed > to address this exact situation, so I am confused why it > seems to be causing the problem... It's like ab tries ::1, > doesn't connect and then fails immediately instead of > then trying 127.0.0.1... Can you run ab under something strace-like to see what it's trying to do? Since the test suite defaults to v4-only, possibly we should switch the test suite to run against http://127.0.0.1:N/ rather than relying on localhost resolving properly, though exposing these bugs is a good thing. Regardsm Joe
Re: Current trunk does not build on Win
To thoroughly confuse... On Tue, Apr 10, 2018 at 10:49 AM, Eric Covener wrote: > On Tue, Apr 10, 2018 at 11:40 AM, William A Rowe Jr > wrote: >> On Tue, Apr 10, 2018 at 7:41 AM, Steffen wrote: >>> >>> Get: >>> >>> Error C2440 'function': cannot convert from 'int (__stdcall *)(conn_rec *)' >>> to 'ap_HOOK_output_pending_t (__cdecl *)' libhttpd >>> ..\VC15\trunk\server\core.c 5724 >> >> '(__stdcall *)(conn_rec *)' != '(__cdecl *) (conn_rec *)' >> >> Callback entry points are generally declared AP_DECLARE_NONSTD >> for this reason. > > It looks like the mod_ssl pattern is that it is not decorated at all. > mod_ssl is the closest to this since it registers non-static functions > from other C files. > They are undecorated. For any non-exported function, undecorated is NONSTD (just not declared). For exported functions, AP_DECLARE "promotes" these to the stdcall API (consistent with most languages default stack args and retval manipulation (except C/C++/ASM). So one can read AP_DECLARE_NONSTD as going right back to the same C/C++ mechanics, only with an exported entry point. Those individual hook callbacks in ssl are static, and registered in an initializer within the same source file. In the declaration static apr_status_t ssl_io_filter_output(ap_filter_t *f, ... this would become SSL_DECLARE_NONSTD(apr_status_t) ssl_io_filter_output(ap_filter_t *f, ... to maintain the very same conventions as previous releases (now with an exported symbol). > ...But we already have this thing in util_filter with AP_DECLARE. > Do we need to wrap it to effectively change to NONSTD or undecorated > for what we register w/ ap_hook_* since it is already public as > AP_DECLARE? Pondering. Right now the stack unwinds would be ridiculous... would substitute the AP_DECLARE with an AP_DECLARE_NONSTD() fn_nonstd() flavor, and then have the originally named function invoke _nonstd(). But why is this an issue? grep -r output_pending in 2.4.x branch in modules/... and server/... shows me nothing. No problem with an MMN major change on 2.5 branch.
2.4.3x regression w/SSL vhost configs
I don't quite understand the new AP_MODULE_FLAG_ALWAYS_MERGE logic so I'm struggling to debug this, but I've had a couple of reports that configurations like: Listen 443 https ServerName www.example.com:443 SSLCertificateFile ... ServerName other.example.com:443 worked in 2.4.29 but now fail to start with: AH02572: Failed to configure at least one certificate and key for other.example.com For the second vhost ap_get_server_protocol(s) returns "https" and triggers the "implicit SSLEngine on" logic. Removing the AP_MODULE_FLAG_ALWAYS_MERGE from the module struct flags (i.e. setting flags to zero) fixes it; I see the 10104 warning in ssl_init_Module is also triggered because the SSLSrvConfigRec is shared across vhosts. Any clues? Regards, Joe
Re: [PATCH 62186] POST request getting logged as GET request
This is a kind reminder that I still didn't get any response yet. Is there any additional information needed from my side? On 03/29/2018 09:09 PM, Micha Lenk wrote: Hi Apache httpd committers, I think I've found a bug which triggers under following conditions: * Apache is configured to serve a local customized error page, e.g. using something like "ErrorDocument 404 /var/www/errors/404.html" * Apache is configured to log the original request's method, e.g. using something like (please note, the "%s %b method=\"%method to "GET" and r->method_number to M_GET before it is calling ap_internal_redirect(custom_response, r) to serve the configured error document. I've tried to fix this issue by taking a backup of the original request's method and restoring it as soon as ap_internal_redirect() returns (see attached patch bz62186_httpd_bugfix.patch). So far the tests I've done are successful, i.e. the request is now correctly logged as POST request. I've filed this issue some days ago as https://bz.apache.org/bugzilla/show_bug.cgi?id=62186 , but so far it didn't get any comments yet. Could anybody please take a look? Kind regards, Micha
Re: Current trunk does not build on Win
On Tue, Apr 10, 2018 at 11:40 AM, William A Rowe Jr wrote: > On Tue, Apr 10, 2018 at 7:41 AM, Steffen wrote: >> >> Get: >> >> Error C2440 'function': cannot convert from 'int (__stdcall *)(conn_rec *)' >> to 'ap_HOOK_output_pending_t (__cdecl *)' libhttpd >> ..\VC15\trunk\server\core.c 5724 > > '(__stdcall *)(conn_rec *)' != '(__cdecl *) (conn_rec *)' > > Callback entry points are generally declared AP_DECLARE_NONSTD > for this reason. It looks like the mod_ssl pattern is that it is not decorated at all. mod_ssl is the closest to this since it registers non-static functions from other C files. They are undecorated. ...But we already have this thing in util_filter with AP_DECLARE. Do we need to wrap it to effectively change to NONSTD or undecorated for what we register w/ ap_hook_* since it is already public as AP_DECLARE? -- Eric Covener cove...@gmail.com
Re: Current trunk does not build on Win
On Tue, Apr 10, 2018 at 7:41 AM, Steffen wrote: > > Get: > > Error C2440 'function': cannot convert from 'int (__stdcall *)(conn_rec *)' > to 'ap_HOOK_output_pending_t (__cdecl *)' libhttpd > ..\VC15\trunk\server\core.c 5724 '(__stdcall *)(conn_rec *)' != '(__cdecl *) (conn_rec *)' Callback entry points are generally declared AP_DECLARE_NONSTD for this reason.
Re: TLSv1.3
On Sun, Apr 8, 2018 at 11:37 AM, Bernard Spil wrote: > Hi Stefan, Mario, > > I saw that 2.5.1-dev was tagged, is another release coming some time soon? Worried me enough to look; http://svn.apache.org/repos/asf/httpd/httpd/tags/ Thankfully nobody made such a tag. You'll note 2.5.0-alpha from a number of months ago; this was the first in development of new tag and release tooling, and as such it never made the cut. No word at this moment of the next 2.5.1-alpha attempt.
Re: ab issues (just on macOS?)
My understanding is that this patch was specifically designed to address this exact situation, so I am confused why it seems to be causing the problem... It's like ab tries ::1, doesn't connect and then fails immediately instead of then trying 127.0.0.1... > On Apr 10, 2018, at 7:14 AM, Jim Jagielski wrote: > > Yeah... this seems related to > >http://svn.apache.org/viewvc?view=revision&revision=1826891 > >> On Apr 10, 2018, at 7:06 AM, Jim Jagielski wrote: >> >> % host localhost. >> localhost has address 127.0.0.1 >> localhost has IPv6 address ::1 >> >> What I think is going on is that ab is using ::1 but httpd is just bound on >> 127.0.0.1 >> >> >>> On Apr 9, 2018, at 7:19 PM, Daniel Ruggeri wrote: >>> >>> That's interesting. Does your machine bind on both IPv6 and IPv4? I would >>> assume just v4 and you have a localhost as ::1 in your hosts file. Is that >>> the case? >>> -- >>> Daniel Ruggeri >>> >>> On April 9, 2018 4:43:42 PM CDT, Jim Jagielski wrote: OK... if I change the test to use 127.0.0.1 instead of localhost, all is well. So I'm guessing it is an IPv6 issue... ? >> >
Current trunk does not build on Win
Get: Error C2440 'function': cannot convert from 'int (__stdcall *)(conn_rec *)' to 'ap_HOOK_output_pending_t (__cdecl *)' libhttpd ..\VC15\trunk\server\core.c 5724 When I remove the hook in core.c : ap_hook_output_pending(ap_filter_output_pending, NULL, NULL, APR_HOOK_MIDDLE); Then it build and runs.
Re: ab issues (just on macOS?)
My test and build system is IPv4 w/ IPv6 Local Link Only. > On Apr 10, 2018, at 7:19 AM, Eric Covener wrote: > > On Tue, Apr 10, 2018 at 7:14 AM, Jim Jagielski wrote: >> Yeah... this seems related to >> >>http://svn.apache.org/viewvc?view=revision&revision=1826891 > > Hrm -- My test config is all ipv4-only on linux (Listen 0.0.0.0:*) so > w/o that patch if localhost returned ::1 first you'd get the same > symptom. > > -- > Eric Covener > cove...@gmail.com
Re: ab issues (just on macOS?)
Some Linux setups mention ::1 for localhost first in /etc/hosts. I vaguely remember once having been bitten by that. > Am 10.04.2018 um 13:19 schrieb Eric Covener : > > On Tue, Apr 10, 2018 at 7:14 AM, Jim Jagielski wrote: >> Yeah... this seems related to >> >>http://svn.apache.org/viewvc?view=revision&revision=1826891 > > Hrm -- My test config is all ipv4-only on linux (Listen 0.0.0.0:*) so > w/o that patch if localhost returned ::1 first you'd get the same > symptom. > > -- > Eric Covener > cove...@gmail.com
Re: buildbot success in on httpd-trunk
Hi Steffen, Am 10.04.2018 um 12:36 schrieb Steffen: Fits the subject: someone says he has success , but I have no success to build Trunk revision 1828799 (current). OK, I got confused by your followup mail talking about copying files from trunk to 2.4. By the way: this "someone" is buildbot, an automated system making a standardized (unix) build for trunk and sending a mail, whenever the build status changes. We tyicaly reply to these mails, if the buildbot build fails and we want to discuss why it failed. For problems observed during our own testing we typically start a new descriptive mail thread. Error C2440 'function': cannot convert from 'int (__stdcall *)(conn_rec *)' to 'ap_HOOK_output_pending_t (__cdecl *)'libhttpd...\trunk\server\core.c5724 Had to remove an unused hook in core.c : ap_hook_output_pending(ap_filter_output_pending, NULL, NULL, APR_HOOK_MIDDLE); Now I am confused again. These are new errors? Or is it your first attempt of building trunk? The code was introduced back in 2016: r1734656 | minfrin | 2016-03-12 01:43:58 +0100 (Sat, 12 Mar 2016) | 3 lines core: Extend support for setting aside data from the network input filter to any connection or request input filter. I don't think the code is unused, so it should not be removed. Unfortunately I don't know enough about how hooks work on Windows to propose a solution. Builds fine now with OpenSSL 1.1.1 pre4, tls1.3 test looks promising. Thanks. The below errors was my fault, was mixing, sorry. OK, no problem. Regards, Rainer On Monday 09/04/2018 at 19:22, Rainer Jung wrote: Hi Steffen, are the below errors you reported from building trunk or from building 2.4? Your mail subject was "Re: buildbot success in on httpd-trunk" so I thought trunk but after trying for quite some time couldn't find any reason for problems there. Your second email makes me wonder whether you copied trunk files to a 2.4 source tree, which is in most cases not a good idea. So can you clarify what you tried and choose an appropriate email subject, so tat we can see from the subject, what the topic is? Thanks and regards, Rainer Am 09.04.2018 um 16:59 schrieb Steffen: Looks cannot build without other sources from trunk, like maybe ap_mmn.h util_filter.h core_filters.c request.c util_filter.c Can we have a patch for 2.4 ? On Monday 09/04/2018 at 16:37, Steffen wrote: Current trunk still does not build mod_ssl on windows: Got: ssl_engine_io.obj : error LNK2019: unresolved external symbol _ap_filter_reinstate_brigade referenced in function _ssl_io_filter_output ssl_engine_io.obj : error LNK2019: unresolved external symbol _ap_filter_should_yield referenced in function _ssl_io_filter_output ssl_engine_io.obj : error LNK2019: unresolved external symbol _ap_filter_setaside_brigade referenced in function _ssl_io_filter_output And warnings with same vcar's: WarningC4013'ap_filter_reinstate_brigade' undefined; assuming extern returning intmod_sslc:\vc15\win32\httpd-2.4\modules\ssl\ssl_engine_io.c1782 WarningC4013'ap_filter_should_yield' undefined; assuming extern returning intmod_sslc:\vc15\win32\httpd-2.4\modules\ssl\ssl_engine_io.c1808 WarningC4013'ap_filter_setaside_brigade' undefined; assuming extern returning intmod_sslc:\vc15\win32\httpd-2.4\modules\ssl\ssl_engine_io.c1865 Cannot figure out if I miss an include. On Monday 09/04/2018 at 16:17, build...@apache.org wrote: The Buildbot has detected a restored build on builder httpd-trunk while building . Full details are available at: https://ci.apache.org/builders/httpd-trunk/builds/1995 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: bb_slave6_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'httpd-trunk-on-commit' triggered this build Build Source Stamp: [branch httpd/httpd/trunk] 1828723 Blamelist: icing Build succeeded! Sincerely, -The Buildbot
Re: ab issues (just on macOS?)
On Tue, Apr 10, 2018 at 7:14 AM, Jim Jagielski wrote: > Yeah... this seems related to > > http://svn.apache.org/viewvc?view=revision&revision=1826891 Hrm -- My test config is all ipv4-only on linux (Listen 0.0.0.0:*) so w/o that patch if localhost returned ::1 first you'd get the same symptom. -- Eric Covener cove...@gmail.com
Re: ab issues (just on macOS?)
Yeah... this seems related to http://svn.apache.org/viewvc?view=revision&revision=1826891 > On Apr 10, 2018, at 7:06 AM, Jim Jagielski wrote: > > % host localhost. > localhost has address 127.0.0.1 > localhost has IPv6 address ::1 > > What I think is going on is that ab is using ::1 but httpd is just bound on > 127.0.0.1 > > >> On Apr 9, 2018, at 7:19 PM, Daniel Ruggeri wrote: >> >> That's interesting. Does your machine bind on both IPv6 and IPv4? I would >> assume just v4 and you have a localhost as ::1 in your hosts file. Is that >> the case? >> -- >> Daniel Ruggeri >> >> On April 9, 2018 4:43:42 PM CDT, Jim Jagielski wrote: >>> OK... if I change the test to use 127.0.0.1 instead of localhost, all >>> is well. So I'm guessing it is an IPv6 issue... ? >
Re: ab issues (just on macOS?)
% host localhost. localhost has address 127.0.0.1 localhost has IPv6 address ::1 What I think is going on is that ab is using ::1 but httpd is just bound on 127.0.0.1 > On Apr 9, 2018, at 7:19 PM, Daniel Ruggeri wrote: > > That's interesting. Does your machine bind on both IPv6 and IPv4? I would > assume just v4 and you have a localhost as ::1 in your hosts file. Is that > the case? > -- > Daniel Ruggeri > > On April 9, 2018 4:43:42 PM CDT, Jim Jagielski wrote: >> OK... if I change the test to use 127.0.0.1 instead of localhost, all >> is well. So I'm guessing it is an IPv6 issue... ?
Re: buildbot success in on httpd-trunk
Fits the subject: someone says he has success , but I have no success to build Trunk revision 1828799 (current). Error C2440 'function': cannot convert from 'int (__stdcall *)(conn_rec *)' to 'ap_HOOK_output_pending_t (__cdecl *)' libhttpd ...\trunk\server\core.c 5724 Had to remove an unused hook in core.c : ap_hook_output_pending(ap_filter_output_pending, NULL, NULL, APR_HOOK_MIDDLE); Builds fine now with OpenSSL 1.1.1 pre4, tls1.3 test looks promising. The below errors was my fault, was mixing, sorry. On Monday 09/04/2018 at 19:22, Rainer Jung wrote: Hi Steffen, are the below errors you reported from building trunk or from building 2.4? Your mail subject was "Re: buildbot success in on httpd-trunk" so I thought trunk but after trying for quite some time couldn't find any reason for problems there. Your second email makes me wonder whether you copied trunk files to a 2.4 source tree, which is in most cases not a good idea. So can you clarify what you tried and choose an appropriate email subject, so tat we can see from the subject, what the topic is? Thanks and regards, Rainer Am 09.04.2018 um 16:59 schrieb Steffen: Looks cannot build without other sources from trunk, like maybe ap_mmn.h util_filter.h core_filters.c request.c util_filter.c Can we have a patch for 2.4 ? On Monday 09/04/2018 at 16:37, Steffen wrote: Current trunk still does not build mod_ssl on windows: Got: ssl_engine_io.obj : error LNK2019: unresolved external symbol _ap_filter_reinstate_brigade referenced in function _ssl_io_filter_output ssl_engine_io.obj : error LNK2019: unresolved external symbol _ap_filter_should_yield referenced in function _ssl_io_filter_output ssl_engine_io.obj : error LNK2019: unresolved external symbol _ap_filter_setaside_brigade referenced in function _ssl_io_filter_output And warnings with same vcar's: WarningC4013'ap_filter_reinstate_brigade' undefined; assuming extern returning intmod_sslc:\vc15\win32\httpd-2.4\modules\ssl\ssl_engine_io.c1782 WarningC4013'ap_filter_should_yield' undefined; assuming extern returning intmod_sslc:\vc15\win32\httpd-2.4\modules\ssl\ssl_engine_io.c1808 WarningC4013'ap_filter_setaside_brigade' undefined; assuming extern returning intmod_sslc:\vc15\win32\httpd-2.4\modules\ssl\ssl_engine_io.c1865 Cannot figure out if I miss an include. On Monday 09/04/2018 at 16:17, build...@apache.org wrote: The Buildbot has detected a restored build on builder httpd-trunk while building . Full details are available at: https://ci.apache.org/builders/httpd-trunk/builds/1995 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: bb_slave6_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'httpd-trunk-on-commit' triggered this build Build Source Stamp: [branch httpd/httpd/trunk] 1828723 Blamelist: icing Build succeeded! Sincerely, -The Buildbot
Re: TLSv1.3
> Am 08.04.2018 um 18:37 schrieb Bernard Spil : > > Hi Stefan, Mario, > > LibreSSL will hopefully add TLSv1.3 to the next version (ca. 6 > months). So I can't test with that just yet. > > Yes, it does work only with Firefox Nightly. :/ Google Chrome Beta > doesn't negotiate 1.3 either. > Using 1.1.1-pre4 at the moment. > The security.tls.version.max in about:config doesn't help... Neither > do the TLS settings in Chrome chrome://flags > > To enable, you MUST add +TLSv1.3 to SSLProtocols? Otherwise it seems I > just get 1.2 No, it should be enabled by default and part of "all" in SSLProtocol. There is discussion if this is a smart move, however I checked in support for client certificates yesterday (needs more testing) that should keep it backward compatible. > I saw that 2.5.1-dev was tagged, is another release coming some time soon? Not that I know of. Cheers, Stefan > > Cheers, Bernard. > > > > 2018-04-03 14:58 GMT+02:00 Stefan Eissing : >> Just added your patch for the latest libressl checks. Thanks! >> >> If I run that version against Firefox Nightly, it negotiates TLSv1.3. That >> is with OpenSSL 1.1.1-pre3; I have no test env for libressl. >> >> Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop. >> >> Cheers, >> >> Stefan >> >>> Am 31.03.2018 um 22:42 schrieb Bernard Spil : >>> >>> I'm running an Apache 2.5.1 snapshot from 2018-03-30 linked against >>> 1.1.1-pre3 from 2018-03-20 (AKA beta 1). >>> >>> If I connect to Apache with openssl 1.1.1 it makes a TLSv1.3 >>> connection. Qualys SSLLabs doesn't see the TLSv1.3 at all. >>> Additionally, Apache doesn't start when SSLOpenSSLConfCmd is used >>> (SSLOpenSSLConfCmd groups secp521r1:secp384r1:x25519) >>> Negotiated connections default to x25519 which is not what I expect. >>> >>> From another host: >>> >>> % /usr/local/bin/openssl version >>> OpenSSL 1.1.1-pre3 (beta) 20 Mar 2018 >>> >>> % /usr/local/bin/openssl s_client -connect test.brnrd.eu:443 >>> CONNECTED(0003) >>> depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 >>> verify return:1 >>> depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 >>> verify return:1 >>> depth=0 CN = test.brnrd.eu >>> verify return:1 >>> >>> --- >>> No client certificate CA names sent >>> Peer signing digest: SHA384 >>> Peer signature type: ECDSA >>> Server Temp Key: X25519, 253 bits >>> --- >>> SSL handshake has read 2696 bytes and written 390 bytes >>> Verification: OK >>> --- >>> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 >>> Server public key is 384 bit >>> Secure Renegotiation IS NOT supported >>> Compression: NONE >>> Expansion: NONE >>> No ALPN negotiated >>> Early data was not sent >>> SSL-Session: >>> Protocol : TLSv1.3 >>> Cipher: TLS_AES_256_GCM_SHA384 >>> Session-ID: >>> Session-ID-ctx: >>> Master-Key: >>> PSK identity: None >>> PSK identity hint: None >>> SRP username: None >>> Start Time: 1522528505 >>> Timeout : 7200 (sec) >>> Verify return code: 0 (ok) >>> Extended master secret: no >>> --- >>> >>> Firefox Nightly and Chrome don't negotiate TLSv1.3 either >>> Am I expecting things that I should not? (Entirely possible :D) >>> >>> Cheers, Bernard. >>> >>> >>> >>> 2018-03-29 16:11 GMT+02:00 Stefan Eissing : Done in r1827992. Cheers, Stefan > Am 29.03.2018 um 12:56 schrieb Greg Stein : > > On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing > wrote: >> ... > That is the intention behind "SSLPolicy modern|intermediate|old" that > configures the TLS stack according to the Mozilla server-side-tls > recommendations. So, one does not have to mess with many directives to > have a site with an "A" SSL Labs rating. > > Besides, except for data center setups, Apache will be used *only* with > https: (and http: redirects to https:) very, very soon. That shifts the > average expertise of an admin setting up a https: site. > > Back to TLSv1.3: > > I do not like to invent new config directives for a new TLS version > either. The protocol on/off switch is now in "SSLProtocol" and that's > where it should be. AFAIK, it's only the cipher list that needs special > treatment (if one wants to override defaults or what SSLPolicy will do > for it, once a recommendation is out). > > Gotcha. > > > So, looking at "SSLCipherSuite". It basically passes the string to the > *SSL library. The manual page makes a big explanation and tables of > ciphers, but the lists repeats basically how OpenSSL cipher strings work. > It would be better to scrap that and replace it with a link to > https://www.openssl.org/docs/man1.0.2/apps/ciphers.html, now that openssl > has nicer documentation) > > Along the gist of your proposal, I think I'll expand "SSLCipherSuite" to > take more than 1 argument and look for optional prefixes to the suite > strings giv
