On Sat, Mar 5, 2022, 11:47 AM Jim Jagielski wrote:
>
> That's where I was heading with this, so I'm an obvious +1 to switching to
> making
> a Github-based workflow "official" for the PMC.
+1
--Jacob
On Mon, Jun 29, 2020 at 1:17 AM Stefan Eissing
wrote:
> 2. Redesign a FOSS httpd v3.x with a new architecture, embracing a
> non-blocking processing model. Maybe under a different name.
Is there widespread interest in this approach (option 2)? It's, in
theory, my preference -- I get the feeling,
On 05/23/2018 10:32 AM, Marion et Christophe JAILLET wrote:
> '--with-test-suite=...' is for the Perl test framework, not for the
> 'test/httpdunit'.
Ah, yes! Thanks for the reminder; --with-test-suite only enables the
`make check` functionality. Sorry, it's been too long.
On 05/23/2018 01:21
On Wed, May 23, 2018, 7:35 AM Micha Lenk wrote:
> > It should only get built if you configure --with-test-suite=... and
> > specify the path to a perl-framework wc. It builds for me in trunk.
>
> Hmm, no difference. It seems to get built independent from whether you
> specify --with-test-suite o
On Nov 4, 2017 8:44 PM, "William A Rowe Jr" wrote:
>> Will it be a fork of latest 2.4.x and trunk things will have to be
>> proposed, voted and backported?
That is not how httpd has operated previously. Again, a proposal
to change the process and a vote is needed if this is desired.
Time for a
On 10/24/2017 11:45 AM, William A Rowe Jr wrote:
On Tue, Oct 24, 2017 at 12:35 PM, Jim Jagielski wrote:
That is way when we backport we transition to RTC, because
we want to ENSURE it's been reviewed.
Wrong. I was there. RTC was adopted in order to ensure both the
reliability but moreso, the
On 08/08/2017 07:19 AM, Stefan Eissing wrote:
PS. @Jchampion: I am not sure how to best merge the unit test cases
into httpd. They need to be optional, tied to the availability of
mod_md and I do not know how to do that.
I need to solve this problem for another module as well (mod_auth_digest
On 08/04/2017 04:38 AM, Luca Toscano wrote:
I agree that mod_macro is flexible enough to improve the reusability of
httpd's configuration, but I don't think that the goals that Stefan has
in mind are satisfiable with your proposed solution.
If we find ourselves doing more of this syntactic sug
On 07/26/2017 04:15 PM, William A. Rowe Jr. wrote:
Yup, thanks for the follow-up! Site is updated and links to
security_vuln24.html#CVE-2017- will now resolve to a sensible
place on our vuln lists.
Thanks for this addition; it's already made navigation much easier for me.
Firefox was com
On 07/24/2017 01:03 PM, Yann Ylavic wrote:
What if the fpm queue in ap_proxy_connect_backend or at POLLOUT time?
If both cases I think the socket is not reused by mod_proxy_fcgi for
the next request, so I don't see how it's a enablereuse issue...
I'm not sure I understand your question, but I t
On 07/24/2017 12:39 PM, Yann Ylavic wrote:
Hmm, don't we close the backend connection (i.e. conn->close = 1)
whenever an error occurs in the fgci loop? What do you mean by
"queue up for later", by whom? Where do that coonection go on the
httpd side?
I mean that the FCGI application (PHP-FPM) h
On 07/24/2017 11:47 AM, Helmut K. C. Tessarek wrote:
I can try to reproduce it when I have set up a VM to run tests.
Unfortunately I currently do not have the time to do so. Maybe in a
few days.
Thanks! If this is the root cause of lost POSTs, then that'd be a good
reason to implement FCGI_GET
vOn 07/24/2017 11:34 AM, Helmut K. C. Tessarek wrote:
On 2017-07-24 13:42, Jacob Champion wrote:
Any chance this is because of the hang I mentioned?
It could be, but this doesn't really change anything.
We can't really help debug your problems very well if we can't reproduc
On 07/24/2017 10:40 AM, Helmut K. C. Tessarek wrote:
In my case it screwed up the POST request by not doing what should have
been done with the request. In the end the request was lost.
(due to timeout, not processing it, or for whatever reason)
Any chance this is because of the hang I mentioned
On 07/19/2017 04:56 AM, Yann Ylavic wrote:
The comment in proxy_fcgi says:
/* This scheme handler does not reuse connections by default, to
* avoid tying up a fastcgi that isn't expecting to work on
* parallel requests. But if the user went out of their way to
* type the
On 07/18/2017 01:38 AM, Luca Toscano wrote:
I didn't do it on purpose because I didn't want to mess with the
main apr_poll, but if you find an elegant solution I am all for it.
It'll take some work, but I think it's doable.
My understanding is that in this case we don't need to listen to
POLL
On 07/14/2017 02:29 AM, Luca Toscano wrote:
http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_fcgi-force_flush-v3.patch
created, I tested it quickly and it seems working fine (still unsure
about using r->connection->pool vs conn->pool in palloc). More tests
following in the weekend :)
Some
On 07/14/2017 03:32 PM, yla...@apache.org wrote:
+ *) mod_proxy_wstunnel: Fix detection of unresponded request which could have
+ led to spurious HTTP 502 error messages sent on upgrade connections.
+ PR 61283
+ trunk patch: http://svn.apache.org/r1754164
+ http://sv
On 07/11/2017 05:36 AM, Yann Ylavic wrote:
I think it's quite hazardous to use/allow ANY and would prefer the
upgrade_method (worker->s->upgrade) to be a list of acceptable
protocols.
I think both ANY *and* NONE are dangerous. Both of them turn
proxy_wstunnel into a generic TCP forwarder (and
Some time this week, I'm going to propose this patch for backport, since
I rely on it for the `make check` feature and I want to get that into 2.4.x.
Rainer, if you (or anyone else) have reservations, please let me know.
--Jacob
On 02/12/2016 09:46 AM, rj...@apache.org wrote:
Author: rjung
Da
On Jul 8, 2017 6:14 PM, "Nick Kew" wrote:
> > > It probably makes sense to work on a nonblocking architecture for
> > > proxied responses in general.
Is that really the issue in the first place? We have a concept of
flushing, and can implement more finely-tuned throughput than merely
blocking v
[x] +1: Good to go
Ubuntu 16.04 x64, test suites for httpd and mod_websocket 0.1.1 with
- APR 1.5.2, APR-Util 1.5.4
- OpenSSL 1.0.2g (Debian)
- event, prefork, worker
- no brotli, no mod_php
--Jacob
On 07/06/2017 12:33 PM, William A Rowe Jr wrote:
[ ] Release 2.2.34 as legacy GA
+1 Ubuntu 16.04, worker/prefork and mod_websocket 0.1.1.
[ ] Retire the 2.2.x branch from any further maintenance.
+1
--Jacob
On 07/06/2017 08:25 PM, Helmut K. C. Tessarek wrote:
On 2017-07-06 14:54, Jacob Champion wrote:
It probably makes sense to work on a nonblocking architecture for
proxied responses in general.
I'm not familiar with that particular code, but would be interested in
looking into it. Does an
On 07/06/2017 11:13 AM, Jim Jagielski wrote:
works 4 me...
Doesn't for me. E.g. with a script like
it takes 1 second to receive a single chunk with both lines in it.
From a quick skim I assume this is because we don't use nonblocking
sockets in the proxy implementation. (There's even a not
On 07/06/2017 10:09 AM, Reindl Harald wrote:
with removing mpm_prefork support for H2 you kill HTTP2 support for a
lot of production setups which may consider switch to H2 in the future
and for sure not rework there whole configuration but put a proxy like
Trafficserver in front and forget abou
On 07/06/2017 08:13 AM, Jim Jagielski wrote:
Due to the questions around lua and apr_table and the
change regarding http2 and prefork, doing a T&R of 2.4.27
right now does not seem prudent. I am holding off until
we determine what to do about both "issues"
IMO we are good to go with mod_lua. CH
On 07/06/2017 07:21 AM, Jim Jagielski wrote:
From IRC:
[10:09:37] I've personally never used apr_table like
described by jchampion_
[10:09:46] and I don't believe it's documented?
[10:10:15] if you want to set a header, you'd use
r.headers_out['foo'] = 'bar'
[10:10:42] so tbh I'd
On 07/05/2017 12:30 PM, Jacob Champion wrote:
So... do we care?
If we do, here's a potential patch to *partially* return to the previous
behavior:
--- modules/lua/lua_apr.c
+++ modules/lua/lua_apr.c
@@ -97,6 +97,12 @@ int ap_lua_init(lua_State *L, apr_pool_t *p)
lua_gettable
On 07/05/2017 11:19 AM, Jacob Champion wrote:
So the effective change is that "apr_table" is no longer a global name,
is that correct?
Unfortunately, from poking around on GitHub, it looks like removing this
global variable might break at least one production script [1]. Not
becau
On 07/04/2017 03:28 PM, rj...@apache.org wrote:
The following lua 5.2 and 5.3 compat change
should be checked for runtime correctness
by someone more knowledgeable about lua.
Index: modules/lua/lua_apr.c
--- modules/lua/lua_apr.c (original)
+++ modules/lua/lua_apr.c Tue Jul 4 20:48:43 2017
@@ -
On 07/05/2017 04:01 AM, Jim Jagielski wrote:
I am curious... what versions of Perl are people using
when running the Perl test framework? It seems that, at least
to me, it is quite picky regarding versions, at least on
macOS.
5.22.1, as distributed with Ubuntu 16.04 (plenty of Debian patches).
On 07/03/2017 04:45 AM, Eric Covener wrote:
+1
+1
--Jacob
On 07/02/2017 08:44 AM, William A Rowe Jr wrote:
I'm reading https://tools.ietf.org/html/rfc3875#section-4.1.5 as the
PATH_INFO is entirely distinct from QUERY_STRING.
Right. SCRIPT_NAME, PATH_INFO, and QUERY_STRING are intended to be three
distinct parts of the Script-URI (see Section 3.3). I
On 06/30/2017 11:40 AM, Jacob Champion wrote:
As far as I can tell it has no downsides, so my only request is that we
add it to CHANGES (or some documentation, somewhere) and get a test in
place before it goes back in. I may be able to get to that later this
afternoon.
This is taking me
On 06/30/2017 09:43 AM, Jim Jagielski wrote:
In any case, I think HEAD of the perl test framework is finally in
shape to test and catch expectations regarding how we
handle FCGI env-vars, both in "generic" situations as well
as how php-fpm sees/expects them. At least, the current
rev "passes" all
On 06/30/2017 08:41 AM, Jacob Champion wrote:
On 06/30/2017 08:37 AM, Jim Jagielski wrote:
Well, in 2.4.26 is WAS/IS an entry in notes available to modules
Well... hm. I guess that's a valid point. My preference is still to
remove it since it's undocumented, but if anyone else wou
On 06/30/2017 08:37 AM, Jim Jagielski wrote:
Well, in 2.4.26 is WAS/IS an entry in notes available to modules
Well... hm. I guess that's a valid point. My preference is still to
remove it since it's undocumented, but if anyone else would like to see
it back in, I'm fine with that.
Other opi
On 06/30/2017 08:10 AM, William A Rowe Jr wrote:
-1 on showstopper. It's a bug, no security implications, cope with it.
Thousands of bugs pass through STATUS, what makes yours special?
It's a reinstatement of my previous 2.4.26 showstopper, which got no
objections, was unaddressed by the prop
On 06/30/2017 05:32 AM, Jim Jagielski wrote:
I still think that the below has value and should not be/have-been
reverted.
I'm not arguing that it doesn't have value in theory, but IMO it doesn't
belong in 2.4.x without a client. Right now it's just dead code.
Anyone opposed to me re-adding
On 06/27/2017 04:59 PM, Eric Covener wrote:
I would just as well pull this block out entirely rather than taking
the "fpm||" half of the test out. It seems like if you go out of your
way to run a script with PATH_INFO set as some parameter that we
shouldn't negate that. And like the non path_in
On 06/28/2017 11:18 AM, Yann Ylavic wrote:
On Wed, Jun 28, 2017 at 7:28 PM, William A Rowe Jr wrote:
Can we get one more pair of eyeballs (or cross-vote the other branch) so
this is properly accepted?
Confirmed on my side for the 2.2.x branch.
And mine, for 2.4.x.
--Jacob
On 06/27/2017 10:21 AM, William A Rowe Jr wrote:
If voters would rather that I address
https://bz.apache.org/bugzilla/show_bug.cgi?id=61220 and reroll, I'm
fine with that.
I think that would be good, since we're planning to make this the Final
Release.
--Jacob
On 06/27/2017 04:39 AM, j...@apache.org wrote:
Author: jim
Date: Tue Jun 27 11:39:02 2017
New Revision: 1800050
URL: http://svn.apache.org/viewvc?rev=1800050&view=rev
Log:
Make this self-contained... Should really pull do_do_run_run
out :)
Removed:
httpd/test/framework/trunk/scripts/uds-te
On 06/27/2017 07:28 AM, j...@apache.org wrote:
Author: jim
Date: Tue Jun 27 14:28:50 2017
New Revision: 1800066
URL: http://svn.apache.org/viewvc?rev=1800066&view=rev
Log:
Re-use the runner sub function...
Modified:
httpd/test/framework/trunk/Misc.pm
httpd/test/framework/trunk/t/modul
On 06/20/2017 11:08 PM, William A Rowe Jr wrote:
Sorry but I reraise my objection and veto worthless cpu cycles.
Hi Bill,
For posterity, can I get a succinct description of your technical
justification for this veto?
--Jacob
On 06/23/2017 01:22 PM, Jim Jagielski wrote:
This is cool. Thx. It's inline with what I was hoping to do.
No problem!
I'm curious though Since we never actually *run* php-fpm on the
PHP script, we never see what PHP actually determines are these
parameters, right?
So like you said on IRC: t
On 06/23/2017 09:42 AM, Jim Jagielski wrote:
Over this weekend I may try to extend the current fcgi testing
to include php-fpm... we should not, imo, fold in any patches
until we can test each applicable use case and avoid regressions.
I've also added one of the known 2.4.26 regressions to the
On 06/21/2017 07:33 AM, j...@apache.org wrote:
Modified: httpd/httpd/trunk/docs/manual/mod/allmodules.xml
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/allmodules.xml?rev=1799455&r1=1799454&r2=1799455&view=diff
===
On 06/22/2017 02:00 AM, Stefan Eissing wrote:
However, running 'make depend' on my dev checkout with a custm --prefix and
libs in that prefix location gives errors such as
/Users/sei/projects/httpd/trunk/modules/filters/mod_xml2enc.c:27:10: fatal
error:
'libxml/encoding.h' file not foun
On 06/21/2017 09:02 AM, William A Rowe Jr wrote:
++1
EXEC_ON_READ is meaningful to we devs, but not for a general audience.
'Immediate Global' or something similar? What other 2 or 3 word caption
works to describe this well for end users researching Define, or
LoadModule, etc?
"Preprocesso
On 06/21/2017 11:58 AM, Jacob Champion wrote:
On 06/21/2017 11:31 AM, Yann Ylavic wrote:
The "make depend" (after initial ./configure) is missing?
Is dependency generation not part of the default make invocation?
...from testing, it looks like it is not. Seems like we should ch
On 06/21/2017 11:31 AM, Yann Ylavic wrote:
The "make depend" (after initial ./configure) is missing?
Is dependency generation not part of the default make invocation?
--Jacob
On 06/20/2017 02:19 PM, Jacob Champion wrote:
Here's why I'm asking: if I were to propose the attached patch for
backport, what is the test case that *should* fail but doesn't?
(proxy_fcgi.t passes, no problem.) And once we get that test case, can
we show that it actually addres
On 06/20/2017 06:39 PM, Jan Ehrhardt wrote:
BTW: the developers at Directadmin are aware of this bug.
https://forum.directadmin.com/showthread.php?t=54952&page=2&p=281618#post281618
I ran into it while updating my Centos 6 servers.
Thanks for the heads up. CC's are coming in on the related bugs
Reverted while the veto is in effect.
On 06/20/2017 11:08 PM, William A Rowe Jr wrote:
Sorry but I reraise my objection and veto worthless cpu cycles.
Yep, but it's public now, which was my goal.
Background for the uninitiated: CVE-2017-7668 is a buffer overrun caused
by Bill's patch in the
On 06/21/2017 09:12 AM, William A Rowe Jr wrote:
If two commits occur in a short enough period of time, the datestamp of
the newly refreshed source may be earlier than the .o generated by the
first update.
The build system won't SVN-update in the middle of a build, and I assume
the build bots
On 06/21/2017 09:06 AM, Jacob Champion wrote:
Now to figure out why it took until the clean rebuild to catch, instead
of the immediate build after the commit.
Oh, there's probably no Makefile dependency on the header, right? Hmm.
--Jacob
On 06/21/2017 09:00 AM, build...@apache.org wrote:
The Buildbot has detected a new failure on builder httpd-trunk while building .
Full details are available at:
https://ci.apache.org/builders/httpd-trunk/builds/682
It works! \o/
Now to figure out why it took until the clean rebuild to c
On 06/21/2017 01:38 AM, Yann Ylavic wrote:
On Wed, Jun 21, 2017 at 10:19 AM, Joe Orton wrote:
I believe many people find the "if constant CMP variable" style
irritating. My internal parser has to reset after reading that because
I assume the LHS is variable on first parse, so I have to mentall
On 06/20/2017 01:35 PM, Jacob Champion wrote:
What requests and server config did you use with this test setup?
Here's why I'm asking: if I were to propose the attached patch for
backport, what is the test case that *should* fail but doesn't?
(proxy_fcgi.t passes, no proble
On 06/20/2017 12:23 PM, Jim Jagielski wrote:
% cat fcgi.pl
#!/usr/bin/env perl
What requests and server config did you use with this test setup?
--Jacob
On 06/20/2017 11:48 AM, Jim Jagielski wrote:
Ahh... the tests from the orig bug report
There have been several reports. I'm hoping to get the test case you
were using to test the new `if (fpm ...` logic in mod_proxy_fcgi. Even
if it was just a manual test; I just want to get it recorded in th
On 06/20/2017 10:55 AM, Jim Jagielski wrote:
It's already in the wild.
We do not guarantee bug compatibility. That's our judgment call based on
adoption, expected user disruption, time in the wild, etc.
The purpose of my Showstopper was to revert to known-good behavior. That
didn't happen,
On 06/20/2017 10:55 AM, Jim Jagielski wrote:
Last I checked, it's in the test framework...
Quick grep for "SCRIPT_NAME" in the tests doesn't turn up anything; can
you point me to it?
--Jacob
On 06/20/2017 09:47 AM, Jacob Champion wrote:
I think. Still trying to context switch back three months.
Jim, do you have a good test case for the current FPM logic so we don't
break that with a fix?
--Jacob
On 06/20/2017 10:12 AM, Jim Jagielski wrote:
All this is, IMO, moot until we have a *patch*.
Agreed. See my other fork of this thread for my questions on that.
Right now there
is a work-around, which, again IMO, reduces the "need" to release
something "now"... the only question is whether the
On 06/20/2017 10:00 AM, William A Rowe Jr wrote:
You must presume it is in the wild, and shortening the exposure
by a matter of days isn't significant.
My point is that we should fix it ASAP. Days vs. more days may not be
significant, but days vs. months is definitely significant when it comes
On 06/20/2017 09:47 AM, wr...@apache.org wrote:
Log:
Make the range test legible
Hmm, out of curiosity, is the legibility you mention from the
parenthesization change or the switch to greater-than-or-equal for one side?
I kind of like reading code that has all less-than comparisons, instead
On 06/20/2017 09:07 AM, Jacob Champion wrote:
Can we do a quick fixup and reroll before it's too late?
And... what *is* the fixup?
It looks like the logic here -- where we start at the end of SCRIPT_NAME
(or the beginning of PATH_INFO) and work backwards -- is designed to
stop at the
On 06/20/2017 09:16 AM, William A Rowe Jr wrote:
It's released into the wild, what is done is done.
Of course. But having it in the wild for three days is different than
having it in the wild for six months.
--Jacob
On 06/20/2017 09:14 AM, William A Rowe Jr wrote:
Would encourage us to wait at least a couple more days for
other, unrelated regression reports to filter in while fixing this
defect. But there is nothing stopping a 2.4.27 in rapid
succession, we simply don't retroactively "retract" releases.
R
On 02/08/2017 07:56 PM, Eric Covener wrote:
Assuming there's some alternate path that actually does change
SCRIPT_NAME by default, we a) don't have any complaint about
SCRIPT_NAME and b) have the SetEnv thing. If we want more options,
maybe we can stash this older SCRIPT_NAME into a new variable
On 06/19/2017 03:44 PM, William A Rowe Jr wrote:
None at all, I have moderation and will push it on.
They are on their way over to you. Thanks for the suggestion.
--Jacob
On 06/19/2017 03:35 PM, William A Rowe Jr wrote:
Not to announce@httpd? users@ and dev@ aren't particularly
broadcast channels.
announce@a.o might be too wide an audience, but that's why
we document the CVE's with short notes in the foundation-wide
release announcement. At least, used to documen
CVE-2017-3169: mod_ssl null pointer dereference
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected:
httpd 2.2.0 to 2.2.32
httpd 2.4.0 to 2.4.25
Description:
mod_ssl may dereference a NULL pointer when third-party modules call
ap_hook_process_connection() during an HTT
CVE-2017-7668: ap_find_token buffer overread
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected:
httpd 2.2.32
httpd 2.4.24 (unreleased)
httpd 2.4.25
Description:
The HTTP strict parsing changes added in 2.2.32 and 2.4.24 introduced a
bug in token list parsing, which a
CVE-2017-7679: mod_mime buffer overread
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected:
httpd 2.2.0 to 2.2.32
httpd 2.4.0 to 2.4.25
Description:
mod_mime can read one byte past the end of a buffer when sending a
malicious Content-Type response header.
Mitigation:
CVE-2017-3167: ap_get_basic_auth_pw authentication bypass
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected:
httpd 2.2.0 to 2.2.32
httpd 2.4.0 to 2.4.25
Description:
Use of the ap_get_basic_auth_pw() by third-party modules outside of the
authentication phase may lead
Slightly late to the party, but
[x] +1: Good to go
Ubuntu 16.04 x64: test suites for httpd and mod_websocket pass with
APR 1.5.2, APR-Util 1.5.4
OpenSSL 1.0.2g (Debian patched)
mpm_event, mpm_prefork, mpm_worker
mod_websocket 0.1.1
I didn't test brotli or PHP. The prefork tests intermittently
On 06/12/2017 08:25 AM, Stefan Eissing wrote:
On 4, it seems, we lack a good http(s) client. The code we use
for proxying is not easily reused for new connections, or? I see
more need for such a thing in the near future.
Did the Apache-Serf-for-proxying effort end up going anywhere? I seem to
On 05/31/2017 08:11 AM, Graham Leggett wrote:
+1 to no-longer-experimental.
+1 to RTC.
+1 to both.
--Jacob
On 05/02/2017 10:14 AM, Ruediger Pluem wrote> On 04/28/2017 10:50 PM,
Jacob Champion wrote:
...why does the EOR bucket have memory ownership of a request_rec,
especially when its lifetime is not well defined? And why have we
put business logic into a finalizer? This is ringing all of my
mem
On 05/29/2017 10:52 PM, Jan Ehrhardt wrote:
Jan Ehrhardt in gmane.comp.apache.devel (Tue, 30 May 2017 07:13:41
+0200):
Steffen in gmane.comp.apache.devel (Mon, 29 May 2017 15:42:46 +0200):
Cmake is now Windows only, is that the goal ?
In what way is it Windows only?
To answer my own questi
Hi all,
Last week I had a personal hackathon since I couldn't make it out to
ApacheCon. As a result there is now a C-language unit test suite
available in branches/httpdunit (based on trunk). I've tested it with a
Windows+CMake toolchain as well as an Ubuntu+autoconf toolchain.
The suite its
On 05/18/2017 10:46 AM, Jim Jagielski wrote:
Based on feedback from various sessions:
Thanks for the list, Jim!
o Warn if the trailing '/'s don't match in ProxyPass/Reverse
directives (eg: ProxyPass /foo http://www.example.com/foo/ )
This one is easy enough to put into the directive
On 04/20/2017 01:06 PM, Gregg Smith wrote:
This is ApacheBench, Version 2.3 <$Revision: 1750960 $>
Same result with trunk, it just hangs.
Glad it's not just Windows!
Gregg, did Rainer's patch work for you on Windows? Looks like it hasn't
been pushed into trunk yet, so I'll apply it today and
On 05/08/2017 11:00 AM, Jim Riggs wrote:
So, who all will be in Miami? From what I've seen on Sched and
messages here:
Yes : jimjag, rich, jfc, ruggeri, me
No : rowe, covener
I won't be able to make it again this year, unfortunately. I'm holding
out hope for ACEU.
Also, contrary to the se
On 05/05/2017 04:42 PM, William A Rowe Jr wrote:
I've been similarly confused. It's obvious that the XML sources have no
context without the XSLT and build stack.
For XSLT, agreed. But as Andre points out there is a way to use the XML
without the build stack, as long as you have a capable brow
On 05/05/2017 01:32 PM, Jim Jagielski wrote:
+1... Lets do it.
BTW, I would adjust #16 to include:
Add the CVE to the CHANGES file.
That way, it's still documented in CHANGES, just after the release
is spun out, show it shows up in the next release's CHANGES.
Sounds good to me.
--Jacob
On 05/05/2017 05:39 AM, Eric Covener wrote:
Here is the change that probably has the biggest impact to the community:
"""
...
The project team commits the fix. No reference should be made to the
commit being related to a security vulnerability.
This is the only part that makes me nervous, sinc
[Re-cc'ing docs. Sorry.]
On 05/05/2017 01:34 AM, André Malo wrote:
Well... It was a split-project back then (in CVS even... :-)). I'm
also not
sure we want all those jar files and stuff in the main repo. Most people
neither use nor need it.
I don't mind having the binaries in a separate place
On 05/05/2017 01:34 AM, André Malo wrote:
Well... It was a split-project back then (in CVS even... :-)). I'm also not
sure we want all those jar files and stuff in the main repo. Most people
neither use nor need it.
I don't mind having the binaries in a separate place, so much as I mind
having
[crossposting dev@ and docs@]
On 05/04/2017 04:55 PM, jchamp...@apache.org wrote:
Author: jchampion
Date: Thu May 4 23:55:48 2017
New Revision: 1793940
URL: http://svn.apache.org/viewvc?rev=1793940&view=rev
Log:
override index: add deps and exclude from all-modules list
I found it a little w
On 05/04/2017 09:39 AM, Jacob Champion wrote:
On 05/04/2017 09:36 AM, William A Rowe Jr wrote:
Ugh... This suggests we've further broken crosscompile, just noticed
this based on your comment.
Why? Cross-compilation uses the same fallback mechanism.
To expand on this, there are three ch
On 05/04/2017 09:36 AM, William A Rowe Jr wrote:
Ugh... This suggests we've further broken crosscompile, just noticed
this based on your comment.
Why? Cross-compilation uses the same fallback mechanism. If a user
doesn't like the conservative choice, he/she should set the cachevars to
overrid
On 05/03/2017 11:25 PM, Ruediger Pluem wrote:
Just as a heads up as I currently don't have time to investigate further. I get
the below on CentOS 6.9 64 bit, which
puzzles me a little bit as I would expect the errno addresses to be different
in different threads on my OS.
[Thu May 04 06:17:13.
On 05/02/2017 02:10 PM, Eric Covener wrote:
I think to be useful, reasonable SSL defaults have to be subject to
change in maintenance (and over-rideable)
So... this got me thinking. If we put this new "stuff" (whatever it
turns out to be) into a new directive,
- part of its operation gets ti
On 05/02/2017 02:01 PM, Helmut K. C. Tessarek wrote:
I'm not sure, how much perf difference there is between A, B, and C, but
SSL by itself has quite an impact
(For the record, our bucket brigade implementation is currently
hamstringing our TLS static file performance, and on top of that OpenS
On 05/02/2017 11:48 AM, William A Rowe Jr wrote:
Are you referring to mod_ssl or a number of modules? If we find such
things, 2.next is our chance to correct any and all unexpected merge
behaviors.
A number of them, but it's less "there are bugs" and more "every
directive/module does its own t
1 - 100 of 365 matches
Mail list logo