To keep this thread moving (additional feedback is welcomed and
appreciated)...
On Thu, Nov 1, 2018 at 5:03 AM Marion & Christophe JAILLET <
christophe.jail...@wanadoo.fr> wrote:
>
> Le 31/10/2018 à 21:52, William A Rowe Jr a écrit :
> >
> > There are 715 reports t
There are 715 reports tagged 2.0.0 through 2.3-HEAD of Status NEW or
NEEDINFO with no Resolution.
For these bugs I believe we should simply close them with a message that
this is a mass-update, that the version is beyond EOL, and a request for
reporters/observers to retest and reopen with the
This doesn't work correctly in 2.4.x... but needs to be fixed in trunk for
2.next.
The problem is that our connection rec structure defers to the vhost
structure
for the port assignment, a 1:1 mapping. We need to break this and trust the
vhost is 1:many, and the connection rec records which
On Fri, Oct 19, 2018 at 6:15 AM Steffen wrote:
> I changed the subject ( was Re: svn commit: r1748461 - in
> /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c)
>
> William A Rowe Jr wrote: ...mod_php or other weirdness
>
> What do you mean by weirdness ? Google tran
On Thu, Oct 18, 2018 at 8:01 AM William A Rowe Jr
wrote:
> On Thu, Oct 18, 2018 at 7:27 AM Rainer Jung
> wrote:
>
>> I get test suite failures for t/ssl/ocsp.t when the server is build
>> against OpenSSL 0.9.8zh. I can't judge on whether that is expected for
>> OpenS
Please never do this again on the eve of a release, it is not easily
reviewed
and is very inconsiderate to the RM. This doesn't meet the idea of minimal
scope, or the spirit of docs@h.a.o being exempt from backport review(!)
That said...
On Thu, Oct 18, 2018 at 7:27 AM Rainer Jung wrote:
> I get test suite failures for t/ssl/ocsp.t when the server is build
> against OpenSSL 0.9.8zh. I can't judge on whether that is expected for
> OpenSSL 0.9.8.
A very good question, and I can't either. Can you confirm your openssl
command line
On Thu, Oct 18, 2018 at 5:21 AM Rainer Jung wrote:
> In trunk we do now have a 2.5 CHANGES file, ie. the file contains
> entries for 2.5.0-alpha and the entries above those under the 2.5.1
> heading.
>
> I think we should add entries under 2.5.1 even if things get likely
> backported and such
On Thu, Oct 18, 2018 at 4:56 AM Rainer Jung wrote:
> - The other one goes back to the other big refactoring which allowed to
> use SSLProxy* directives in containers, first released in 2.4.32
> this year. It fixes a missing config merge (very small patch). This is
> not related to the OpenSSL
https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/ is what will
be exported, ,/buildconf invoked, and then tarred up, if that helps you
anticipate the tag a day early. It shouldn't give any different hassles
than trunk.
On Wed, Oct 17, 2018, 13:31 Dennis Clarke wrote:
> On 10/17/2018
On Fri, Oct 12, 2018 at 4:54 PM William A Rowe Jr
wrote:
> 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
> ag
, and my earlier hint to add
-help would not have improved the situation.
On Sun, Oct 14, 2018 at 3:50 PM Rainer Jung wrote:
> Am 14.10.2018 um 21:59 schrieb William A Rowe Jr:
> > On Sun, Oct 14, 2018 at 8:32 AM Jim Jagielski > <mailto:j...@jagunet.com>> wrote:
> >
On Sun, Oct 14, 2018 at 4:38 PM Dennis Clarke wrote:
>
> As a red herring that illustrates how oddball the situation could get :
>
> $ /usr/sfw/bin/openssl version 2>&1 | cut -f1 -d\(
> OpenSSL 0.9.7d 17 Mar 2004
> [...]
> Segmentation Fault(coredump)
>
I think we can safely ignore OpenSSL
On Wed, Oct 10, 2018 at 12:27 PM wrote:
> Author: jim
> Date: Wed Oct 10 17:27:33 2018
> New Revision: 1843478
>
> @@ -21,7 +21,7 @@ Apache::TestRequest::module('ssl_ocsp');
> # support in earlier versions without messing around with stderr
> my $openssl = Apache::TestSSLCA::openssl();
> if
I see 'ocsp' in both lists, and 2>&1 redirects stderr to stdout
unambiguously,
resulting in correct evaluation of the `openssl list 2>&1` ~! /ocsp/ match.
I will proceed with your veto to remove my " 2>&1" addition, restoring
the original test by jorton, if you would like, and leave this file to
On Mon, Oct 15, 2018 at 10:10 AM Jim Jagielski wrote:
> -1 (veto).
>
Correct. Your three commits against jorton's implementation are vetoed.
They were incorrect.
> 'list' is not a valid command.
>
You are wrong.
The list-standard-commands feature was dropped from OpenSSL 1.1.0 and
onwards.
On Mon, Oct 15, 2018 at 7:52 AM Jim Jagielski wrote:
>
> And lest we forget, the orig version used:
>
> $openssl list -commands
>
> I have no idea what version of openssl supports 'list'. The result
> of which was that the ocsp testing was ALWAYS SKIPPED.
>
No, it wasn't skipped. We weren't
Like my beg for getting us to the 2.4.35 release tag, I'd like to propose
we keep patches to branches/2.4.x/ generally within the scope of
straightening out the remaining quirks related to the OpenSSL 1.1.1 API and
library behavior changes (and similar corrections for any alternate library
On Mon, Oct 15, 2018 at 3:06 AM Stefan Eissing
wrote:
>
> See my mail on the other thread. It seems that h2 traffic triggers a call
> sequence that exposes a change in OpenSSL behaviour of SSL_read() between
> 1.1.0 and 1.1.1. It looks as if mod_ssl interpreted the return codes of
> SSL_read()
On Sun, Oct 14, 2018, 18:47 Rainer Jung wrote:
>
> On the contrary, the http2 tests (other thread) fail for me also with
> curl or browser, but only when the server is build with OpenSSL 1.1.1
> (independent of TLS version used).
>
Goes without saying... But this browser and curl are both built
Dennis, just to confirm ... is this build ocsp enabled, or entirely absent
and yet presenting the ocsp help in absence of the feature?
On Sun, Oct 14, 2018 at 4:38 PM Dennis Clarke wrote:
> On 10/14/2018 05:14 PM, Rainer Jung wrote:
> > Am 14.10.2018 um 22:58 schrieb William
On Sun, Oct 14, 2018 at 3:50 PM Rainer Jung wrote:
>
> And Jim already set "With 1.1.1, both return 1, but so what, we know
> that it has oscp."
>
That, of course, is nonsense.
OpenSSL is malleable... with numerous no-{feature} choice, we really
shouldn't
presume presence of features by
Copy paste missed a stderr line;
$ openssl ocsp >/dev/null
ocsp: Use -help for summary.
$ echo $?
1
$ openssl xyz >/dev/null
Invalid command 'xyz'; type "help" for a list.
$ echo $?
1
$ openssl version
OpenSSL 1.1.0i-fips 14 Aug 2018
This is from
# dnf list openssl
Installed Packages
On Sun, Oct 14, 2018 at 8:32 AM Jim Jagielski wrote:
> All we are checking is the error code. Nothing else.
>
>% openssl version
>OpenSSL 1.0.2p 14 Aug 2018
>% openssl ocsp 2>/dev/null
>% print $?
>1
>% openssl foo 2>/dev/null
>% print $?
>0
>
> With 1.1.1, both
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
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, applin
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:
&g
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:
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
; #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
>>
t; 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,
&
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.
On Wed, Oct 10, 2018, 14:53 Mark Blackman wrote:
>
> Does the TLSv1.3 support need to be production ready?
>
> TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger
> existing behaviours, I would have assumed it’s relatively safe to release
> with caveats in the docs.
> Of
On Wed, Oct 10, 2018, 14:46 Jim Jagielski wrote:
>
> On Oct 10, 2018, at 3:37 PM, William A Rowe Jr
> wrote:
>
> On Wed, Oct 10, 2018, 14:28 Jim Jagielski wrote:
>
>>
>> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr
>> wrote:
>>
>> On W
On Wed, Oct 10, 2018, 09:04 Stefan Eissing
wrote:
>
> Since each pytest module starts httpd and stops it again, the config files
> can be very local to the tests being done. That makes them quite easy to
> understand and startup times very short.
>
Sadly, that's an enormous regression from the
On Wed, Oct 10, 2018, 14:28 Jim Jagielski wrote:
>
>
> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr
> wrote:
>
> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski wrote:
>
>> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
>>
>> If th
On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski wrote:
> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
>
> If that's not ready for prime time, then why a release??
>
AIUI, it isn't that httpd isn't ready for release, or even httpd-test
framework.
Until all the upstream
Huh?!?
$ openssl list-standard-commands
Invalid command 'list-standard-commands'; type "help" for a list.
$ openssl version
OpenSSL 1.1.0i-fips 14 Aug 2018
On Wed, Oct 10, 2018 at 12:18 PM wrote:
> Author: jim
> Date: Wed Oct 10 17:18:27 2018
> New Revision: 1843476
>
> URL:
You might want to review the thread following up svn commit: r1840585
back from Sept 12th w.r.t. some of these.
On Tue, Oct 9, 2018 at 3:29 PM Daniel Ruggeri wrote:
> Hi, all;
> I ran through my usual testing routine, this time with OpenSSL 1.1.1,
> but found several test failures. In the
Since this tag is only days away, the committers would really appreciate
any feedback from early adopters. I'm not certain on the status of the auth
hook fix, but believe it's certainly ready to have the tires kicked, so we
can avoid any quirks resulting from the TLS 1.3 efforts.
Please feel free
On Thu, Oct 4, 2018 at 12:09 PM Evgeny Kotkov
wrote:
>
> However, a more important question is whether there is an actual problem to
> solve. I see that ap_http_header_filter() features a whitelist of headers
> that are sent for 304 responses (http_filters.c:1428), and all headers such
> as
Edit to add, I also found two references on G+...
https://plus.google.com/s/httpd%202.4.35/top
On Mon, Oct 1, 2018 at 7:34 PM William A Rowe Jr
wrote:
> I see some Twitter activity, including;
> https://twitter.com/ApacheLounge/status/1043436704646852608
>
> as well as a v
I see some Twitter activity, including;
https://twitter.com/ApacheLounge/status/1043436704646852608
as well as a very minor FB footprint of some three mentions;
https://www.facebook.com/groups/sistemcihrvatska/permalink/2105437672830472/
Unfortunately, I found nothing on El Reg or MySpace.
On Sat, Sep 29, 2018, 09:25 Daniel Ruggeri wrote:
> Hi, Bill;
>
>Sure. I've updated the scripts to set the reply-to address and also
> fired a message off to ann@a.o to wrap it up. I didn't change the date
> of the announcement, so hopefully that won't pose a problem.
>
Confirming...
Sebb thank you for your analysis!
Two issues; one, the reply-to field of security announcements was set to
security@, and this is in direct contravention of Apache policy. Security@
is exclusively for reporting undisclosed vulnerabilities, and all other
traffic is ignored. This group of email
On Tue, Sep 25, 2018 at 11:56 PM Daniel Ruggeri
wrote:
> FWIW, this was a straight forward multi-To field email message addressed
> to both lists. If there is a way I can improve the announce/release
> automation, I am happy to do so. Maybe a better way is to send multiple
> messages?
>
At some
icated with my ASF
> credentials. I had checked in with Infra here at ACNA and they saw
> *something* that looked like my message. I'll check in with them
> again.
> Thanks, folks
> --
> Daniel Ruggeri
> On September 24, 2018 3:07:00 PM EDT, William A Rowe Jr
> wrote:
&
I'm seeing no announce@httpd moderation request. (I am not an
annou...@apache.org moderator.)
Did you send from your @apache.org avail-id through the ASF server? It would
be rejected for non-apache and for mismatched SPF records.
On Mon, Sep 24, 2018 at 9:16 AM Daniel Ruggeri wrote:
> Hi,
You might want to point out the -r flag to OpenSSL, which emits the same
output as bintools sha256.
On Fri, Sep 21, 2018, 12:30 wrote:
> Author: elukey
> Date: Fri Sep 21 17:30:07 2018
> New Revision: 1841620
>
> URL: http://svn.apache.org/viewvc?rev=1841620=rev
> Log:
> Remove MD5 traces from
On Fri, Sep 21, 2018 at 12:09 PM Dennis Clarke
wrote:
> On 09/21/2018 12:27 PM, William A Rowe Jr wrote:
> > You may want to use this opportunity to drop md5 and sha1 hashes, you
> > will be yelled at by ops when you attempt to publish new instances of
> > these obsoleted
You may want to use this opportunity to drop md5 and sha1 hashes, you will
be yelled at by ops when you attempt to publish new instances of these
obsoleted hashes.
In the apr release case, the announce was modded through anyways, but a
subsequent thread on dev@apr determined that only sha256 is
On Mon, Sep 17, 2018 at 7: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:
On Thu, Sep 20, 2018 at 4:41 AM Plüm, Rüdiger, Vodafone Group <
ruediger.pl...@vodafone.com> wrote:
> Can we have set it to info? Debug is very verbose for SSL just to find out
> why a HTTP request was replied to with a 403.
>
Whatever is appropriate on startup/graceful restart is fine, but
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
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
On Tue, Sep 18, 2018 at 1:56 PM Ruediger Pluem 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
On Tue, Sep 18, 2018 at 2:43 AM Joe Orton wrote:
> On Mon, Sep 17, 2018 at 06:16:34PM -0500, Daniel Ruggeri wrote:
> >Sorry - I know it wasn't a very good report. I was just seeing if
> > anyone has experienced a similar holdup. In fact, I let it run while
> > tending to other things and
That was odd.
Consistent with the new literal characters in place of 's which was
discussed and accepted on list. Imagine nobody had performed the
`build.sh all` step in a little while.
Rev change was correct, so that's a positive. Will be testing shortly,
but optimistic. Thanks for RM'ing!
On
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 with
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
On Mon, Sep 17, 2018 at 12:08 PM William A Rowe Jr
wrote:
> I'm similarly examining the win32 cmake build in anticipation.
>
> Thus far, the only issue is the mis-inclusion of applink.c; this is broken
> with openssl 1.1.1. Looking now for a resolution.
>
There is an issu
I'm similarly examining the win32 cmake build in anticipation.
Thus far, the only issue is the mis-inclusion of applink.c; this is broken
with openssl 1.1.1. Looking now for a resolution.
On Mon, Sep 17, 2018 at 10:02 AM Daniel Ruggeri
wrote:
> Hi, all;
>
> STATUS is looking clean and my test
On Mon, Sep 17, 2018 at 10:52 AM Jim Jagielski wrote:
> Would like to also propose for apr-1.7...
>
> *Subject: **svn commit: r1841078 - in /apr/apr/trunk: CHANGES apr.dsp
> atomic/unix/builtins64.c atomic/unix/mutex64.c atomic/win32/apr_atomic64.c
> include/apr_atomic.h
It is entirely appropriate to turn down the volume. That's what
module-by-module loglevels are there for.
On Mon, Sep 17, 2018, 02:56 Stefan Eissing
wrote:
> Just a quick question, if we can reach consensus here:
>
> mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when
>
As recently disclosed in;
https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2016-4975
Sergey Bobrov brought this disclosure of a moderate vulnerability in
mod_userdir to the httpd project security@ team. Given various examples of
invalid and valid request URL's, even the valid input
I'm unaware of anything blocking a tag today, if someone wants to proceed.
What is gained by waiting a few days to slip in another rushed patch to
break yet another release?
I see nothing in STATUS necessary to fix 2.4 regressions, but many proposed
behavioral changes which suggest the likelyhood
On Tue, Sep 11, 2018 at 8:01 AM Jim Jagielski wrote:
> If there is still interest, there are a handful of useful backports in
> STATUS that could use review, testing and voting :-)
>
Unless the goal is to replace one set of regressions with a new set
of regressions, it's past due to tag 2.4.35
On Wed, Sep 12, 2018, 09:19 Graham Leggett wrote:
> On 12 Sep 2018, at 15:39, William A Rowe Jr wrote:
>
> > Now, why would we *need* a 2.5.x branch?
>
> The primary need is to remove stuff that we deem not-ready-for-2.6-yet.
> Modules without any docs for example wo
Going to largely ignore most other input on this thread, beyond the
underlying proposals to branch 2.5.x and move to RTC...
On Wed, Sep 12, 2018, 03:20 Stefan Eissing
wrote:
> In my estimation, cleaning up trunk (or a copy of it) via RTC will take
> forever, at least.
>
> And while that
On Wed, Sep 12, 2018 at 7:49 AM Jim Jagielski wrote:
> As I said before, the main assumption in my suggestion is that there are
> things in trunk that "really should" be in some releasable version
Everything in trunk is now digested into three groups of commits, for
inspection. These don't
On Wed, Sep 12, 2018, 07:41 Jim Jagielski wrote:
> Ahh. I think I see the problem! For some reason Bill sees this as somehow
> Jim's (my) fork. It's not. It's a svn branch from HEAD of trunk, which
> contains
> all the changes. That branch is the projects's branch not some personal
> fork,
On Wed, Sep 12, 2018, 04:16 Daniel Gruno wrote:
> On 09/12/2018 10:58 AM, Graham Leggett wrote:
> > On 12 Sep 2018, at 03:15, William A Rowe Jr > <mailto:wr...@rowe-clan.net>> wrote:
> >
> >> On Tue, Sep 11, 2018, 17:42 Graham Leggett >> <mailto:
On Tue, Sep 11, 2018, 13:35 Jim Jagielski wrote:
>
> And finally, we have some things in trunk that will likely
> need to be majorly fixed or else scrapped.
>
Please catalog these things.
The reason that even-odds minor versions exist is to clean up trunk for a
GA release. Otherwise we would
On Tue, Sep 11, 2018, 17:42 Graham Leggett wrote:
> On 11 Sep 2018, at 20:35, Jim Jagielski wrote:
>
> > This is what I propose:
> >
> > o Later on this week I svn cp trunk over to branches/2.5.x
>
-1 ... Veto on the basis of project bylaws. Propose a revision for voting.
> o That branch
On Thu, Sep 6, 2018 at 3:13 AM Stefan Eissing
wrote:
>
> > I can't imagine the project releasing this changeset without first
> releasing
> > a stable 2.4.35, followed shortly thereafter with a less stable TLS 1.3
> > release. It appears to introduce a set of required(?) config changes,
> >
On Fri, Sep 7, 2018 at 4:52 AM Yann Ylavic wrote:
>
> There probably are other "includes/" candidates, like:
> ap_expr_init (ap_expr.h)
> ap_open_logs (http_log.h)
> ap_logs_child_init (http_log.h)
> ap_add_output_filters_by_type (http_core.h)
> ap_core_reorder_directories
I'd suggest you did a better job in the commit log explaning this than in
the doxygen where it really is needed.
Private declares don't belong in util_filter.h IMO.
On Thu, Sep 6, 2018, 17:48 wrote:
> Author: ylavic
> Date: Thu Sep 6 22:48:28 2018
> New Revision: 1840265
>
> URL:
On Wed, Sep 5, 2018 at 10:52 AM, Dennis Clarke
wrote:
> On 09/05/2018 07:36 AM, Stefan Eissing wrote:
>
>> A member of the OpenSSL project gave me a "go ahead" and we now have
>> branch:
>>
>> https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x
>>
>> as a copy of 2.4.x with
As we unwind various regressions and breakage, one non-lethal but somewhat
horrid report stands out. Eric correctly tied it to the patch applied for
https://bz.apache.org/bugzilla/show_bug.cgi?id=62590 in the 2.4.24
timeframe.
Server Software:Apache/2.2.34
SSL/TLS Protocol:
MMN major, please?
On Fri, Aug 24, 2018 at 2:46 PM, wrote:
> Author: jim
> Date: Fri Aug 24 19:46:57 2018
> New Revision: 1838941
>
> URL: http://svn.apache.org/viewvc?rev=1838941=rev
> Log:
> better struct layout ...
>
> Modified:
> httpd/httpd/trunk/modules/proxy/mod_proxy.h
>
> Modified:
On Fri, Jul 20, 2018 at 2:27 PM, wrote:
> Author: rpluem
> Date: Fri Jul 20 19:27:31 2018
> New Revision: 1836381
>
> URL: http://svn.apache.org/viewvc?rev=1836381=rev
> Log:
> * mod_proxy: Remove load order and link dependency between mod_lbmethod_*
> modules and mod_proxy by providing
reports, or our own observed and fixed defects helps users later answer
their own questions, reducing the number of duplicate reports on list. Well
worth that initial effort.
On Thu, Aug 9, 2018, 06:35 Jim Jagielski wrote:
>
>
> > On Aug 9, 2018, at 12:11 AM, William A Rowe
On Thu, Aug 9, 2018 at 1:06 PM, Eric Covener wrote:
> On Thu, Aug 9, 2018 at 11:02 AM Jim Jagielski wrote:
> >
> > Anyone having issues w/ the above test hanging after test 182?
> >
> > On the 2.4.x branch it runs thru to completion, but on trunk (macOS),
> > stalls after 182:
>
> For me on
On Wed, Aug 8, 2018, 23:11 William A Rowe Jr wrote:
> On Tue, Aug 7, 2018, 10:55 Jim Jagielski wrote:
>
>>
>>
>> On Aug 7, 2018, at 11:21 AM, William A Rowe Jr
>> wrote:
>>
>>
>> Specific regressions as requested by Jim, posted on users@ and dev@
On Tue, Aug 7, 2018, 10:55 Jim Jagielski wrote:
>
>
> On Aug 7, 2018, at 11:21 AM, William A Rowe Jr
> wrote:
>
>
> Specific regressions as requested by Jim, posted on users@ and dev@
> which are showstoppers to upgrading for some;
>
> - Non-HTTP responses f
On Mon, Aug 6, 2018 at 6:38 PM, Noel Butler wrote:
> On 07/08/2018 03:37, William A Rowe Jr wrote:
>
> It appears 2.4.34 is unusable, as other distributors also paused to start
> hauling in regression fixes as they
>
> eh? unusable? I have rooms full of them with no
On Mon, Aug 6, 2018 at 12:37 PM, William A Rowe Jr
wrote:
> Is anyone else disappointed in the number of regressions in 2.4.35?
>
> Is anyone else interested in releasing 2.4.36 promptly with no new
> features or enhancements which may cause 2.4.36 to be similarly unusable?
>
Is anyone else disappointed in the number of regressions in 2.4.35?
Is anyone else interested in releasing 2.4.36 promptly with no new features
or enhancements which may cause 2.4.36 to be similarly unusable? Which
backports or reversions of new code are still needed to get to that point?
It
I'd concur that this suggested change is lighter weight and less fragile.
On Fri, Jul 27, 2018, 12:56 Cory McIntire wrote:
> Hi Luca,
>
> Sorry for the delay in response.. we did look into it further..
>
> On of our devs had been looking into it and came up with the following:
>
> {quote}
>
gt; make[4]: *** [proxy_util.slo] Error 1
>
> make[3]: *** [shared-build-recursive] Error 1
>
> make[2]: *** [shared-build-recursive] Error 1
>
> make[1]: *** [shared-build-recursive] Error 1
>
> make: *** [all-recursive] Error 1
>
>
>
> The attached one which is s
proxy_is_best_callback_fn_t
> *is_best,
>
> Index: modules/proxy/proxy_util.c
>
> ===
>
> --- modules/proxy/proxy_util.c (revision 1836460)
>
> +++ modules/proxy/proxy_util.c (working copy)
>
Perhaps use proxy_balancer_get_best_worker, and don't export
that? That can be the delegate for ap_proxy_balancer_get_best_worker.
We either keep callbacks local, or export them _NONSTD. All the
*_DECLARE (without _NONSTD) are not usable as apr/httpd
callbacks.
On Mon, Jul 23, 2018 at 7:22 AM,
On Fri, Jul 20, 2018, 15:22 Ruediger Pluem wrote:
>
> BTW: We have the same load order issue issue with the following proxy
> modules:
>
> mod_proxy_connect
> mod_proxy_ftp
> mod_proxy_http
> mod_proxy_fcgi
> mod_proxy_scgi
> mod_proxy_fdpass
> mod_proxy_ajp
> mod_proxy_balancer
>
018 08:24 PM, William A Rowe Jr wrote:
> > On Thu, May 31, 2018 at 8:24 AM, mailto:j...@apache.org>>
> wrote:
> >
> > Author: jim
> > Date: Thu May 31 13:24:04 2018
> > New Revision: 1832609
> >
> > URL: http://svn.apache.org/viewvc?
FWIW, the correct fix seems to be to fix the regression in
http://svn.apache.org/viewvc?rev=1832609=rev rather than the windows
build.
On Thu, Jul 19, 2018, 13:18 William A Rowe Jr wrote:
> Hi Michal, thanks for your report.
>
> On Thu, Jul 19, 2018 at 10:36 AM, Michal Karm
> wr
Hi Michal, thanks for your report.
On Thu, Jul 19, 2018 at 10:36 AM, Michal Karm
wrote:
> Hi guys,
>
> I would like to ask whether there are any plans on
> accepting [1] patch to 2.4.x as it keeps failing the CMake Windows build.
>
> Furthermore, there is a regression [2] in 2.4.34 CMake
This came up on another channel, but seems to be general interest;
On Thu, Jul 19, 2018 at 12:18 PM, William A Rowe Jr
wrote:
>
> I'm at a loss to point to the canonical list of experimental components.
>
Is this it? Are there another authoritative list for 2.4.35-dev?
$ grep &quo
It might be worth comparing our trunk and 2.4.33 since we have had a lot of
discussion and some work around renegotiation behavior. Confirmation that
this is not new would be great.
On Tue, Jul 10, 2018, 14:26 Eric Covener wrote:
> I tried testing the latest candidate w/ openssl 1.1.1-pre8 and
I can get their efforts committed late this evening, if nobody beats me to
it. Expect to need a bit of crlf tweaking.
On Thu, Jul 5, 2018, 12:36 Marion et Christophe JAILLET <
christophe.jail...@wanadoo.fr> wrote:
> +1, but latest zh-cn and zh-tw translation of error pages should be
> included
On Mon, Jul 2, 2018 at 8:25 AM, Stefan Eissing wrote:
> I thought experimental == CTR, but if this is separate then I‘ll go
> through the votes. Just let me know what you prefer.
I basically thought the same thing, but it is clearly spelled out in STATUS.
We aught to adjust this to reflect the
101 - 200 of 6128 matches
Mail list logo
