Re: backports

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

Re: iOS 14 / macOS 11 and HTTP/3 support

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

Re: Experimental C unit test suite available for hacking

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

Re: Experimental C unit test suite available for hacking

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

Re: We have soon 5 SVN repo's

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

Re: Thoughts on 2.5.0

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

Re: trunk-md merge pending

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

Re: SSLPolicy

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

Re: svn commit: r1803072 - /httpd/site/trunk/content/security/vulnerabilities-httpd.page/securitydb.xsl

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

Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml

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

Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml

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)

Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml

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

Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml

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

Re: svn commit: r1802336 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_fcgi.xml

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

Re: mod_proxy_fcgi and flush

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

Re: mod_proxy_fcgi and flush

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

Re: svn commit: r1801997 - /httpd/httpd/branches/2.4.x/STATUS

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 +

Re: svn commit: r1801594 - in /httpd/httpd/trunk: docs/manual/mod/mod_proxy_wstunnel.xml modules/proxy/mod_proxy_wstunnel.c

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

Re: svn commit: r1730079 - in /httpd/httpd/trunk: Makefile.in acinclude.m4 build/config_vars.sh.in

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

Re: mod_proxy_fcgi and flush

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

Re: [VOTE] Release Apache httpd 2.4.27 as GA

[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

Re: [VOTE] Release httpd-2.2.34

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

Re: mod_proxy_fcgi and flush

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 anybody

Re: mod_proxy_fcgi and flush

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

Re: 2.4.27

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

Re: 2.4.27 T ... holding off

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 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.

Re: svn commit: r1800835 - in /httpd/httpd/branches/2.4.x: ./ CHANGES modules/lua/README modules/lua/config.m4 modules/lua/lua_apr.c modules/lua/lua_config.c modules/lua/lua_request.c modules/lua/mod_

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

Re: svn commit: r1800835 - in /httpd/httpd/branches/2.4.x: ./ CHANGES modules/lua/README modules/lua/config.m4 modules/lua/lua_apr.c modules/lua/lua_config.c modules/lua/lua_request.c modules/lua/mod_

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(L, 2

Re: svn commit: r1800835 - in /httpd/httpd/branches/2.4.x: ./ CHANGES modules/lua/README modules/lua/config.m4 modules/lua/lua_apr.c modules/lua/lua_config.c modules/lua/lua_request.c modules/lua/mod_

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

Re: svn commit: r1800835 - in /httpd/httpd/branches/2.4.x: ./ CHANGES modules/lua/README modules/lua/config.m4 modules/lua/lua_apr.c modules/lua/lua_config.c modules/lua/lua_request.c modules/lua/mod_

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 @@

Re: perl test framework

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).

Re: 2.4.27

On 07/03/2017 04:45 AM, Eric Covener wrote: +1 +1 --Jacob

Re: FastCGI env-vars

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).

Re: svn commit: r1800306 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_actions.c modules/proxy/mod_proxy_fcgi.c

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

Re: FastCGI env-vars

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"

Re: svn commit: r1800306 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_actions.c modules/proxy/mod_proxy_fcgi.c

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 would like

Re: svn commit: r1800306 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_actions.c modules/proxy/mod_proxy_fcgi.c

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

Re: svn commit: r1800307 - /httpd/httpd/branches/2.4.x/STATUS

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

Re: svn commit: r1800306 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_actions.c modules/proxy/mod_proxy_fcgi.c

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

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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

Re: svn commit: r1800181 - /httpd/httpd/branches/2.4.x/STATUS

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.

Re: [VOTE] Release httpd-2.2.33

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

Re: svn commit: r1800050 - in /httpd/test/framework/trunk: scripts/uds-test.pl t/modules/proxy.t

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=rev Log: Make this self-contained... Should really pull do_do_run_run out :) Removed:

Re: svn commit: r1800066 - in /httpd/test/framework/trunk: Misc.pm t/modules/proxy_fcgi.t

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=rev Log: Re-use the runner sub function... Modified: httpd/test/framework/trunk/Misc.pm

Re: svn commit: r1799375 - /httpd/httpd/trunk/server/util.c

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

Re: svn commit: r1799689 - in /httpd/test/framework/trunk/t: conf/proxy.conf.in htdocs/modules/proxy/fcgi/ htdocs/modules/proxy/fcgi/index.php modules/proxy_fcgi.t

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:

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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

Re: svn commit: r1799455 - /httpd/httpd/trunk/docs/manual/mod/

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=1799454=1799455=diff

Re: buildbot failure in on httpd-trunk

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

Re: [users@httpd] if directive not being respected in Apache 2.4.6

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?

Re: buildbot failure in on httpd-trunk

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 sho

Re: buildbot failure in on httpd-trunk

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

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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 addresses a valid PHP

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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=2=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 in

Re: svn commit: r1799375 - /httpd/httpd/trunk/server/util.c

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

Re: buildbot failure in on httpd-trunk

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

Re: buildbot failure in on httpd-trunk

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

Re: buildbot failure in on httpd-trunk

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

Re: svn commit: r1799356 - in /httpd/httpd/branches/2.2.x: ./ server/scoreboard.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,

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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 problem.) And once we

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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,

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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

Re: svn commit: r1799356 - in /httpd/httpd/branches/2.2.x: ./ server/scoreboard.c

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

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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 first

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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.

Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS

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

Re: CVE-2017-3167: ap_get_basic_auth_pw authentication bypass

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

Re: CVE-2017-3167: ap_get_basic_auth_pw authentication bypass

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

CVE-2017-3169: mod_ssl null pointer dereference

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

CVE-2017-7668: ap_find_token buffer overread

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

CVE-2017-7679: mod_mime buffer overread

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.

CVE-2017-3167: ap_get_basic_auth_pw authentication bypass

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

Re: [VOTE] Release Apache httpd 2.4.26 as GA

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

Re: ocsp stapling improvements

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

Re: HTTP/2 and no-longer "experimental"

On 05/31/2017 08:11 AM, Graham Leggett wrote: +1 to no-longer-experimental. +1 to RTC. +1 to both. --Jacob

Re: svn commit: r1707087 - /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c

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

Re: The drive for 2.4.26

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

Experimental C unit test suite available for hacking

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

Re: Ideas from ApacheCon

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

Re: The drive for 2.4.26

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

Re: ACNA Miami: Who? When?

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

Re: svn commit: r1793940 - in /httpd/docs-build/trunk: deps.xml lib/allmodules.pl

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

Re: Change from ad-hoc/historical security process to ASF process?

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

Re: Change from ad-hoc/historical security process to ASF process?

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,

Re: svn commit: r1793940 - in /httpd/docs-build/trunk: deps.xml lib/allmodules.pl

[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

Re: svn commit: r1793940 - in /httpd/docs-build/trunk: deps.xml lib/allmodules.pl

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

Re: svn commit: r1793940 - in /httpd/docs-build/trunk: deps.xml lib/allmodules.pl

[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=rev Log: override index: add deps and exclude from all-modules list I found it a little weird

Re: Fixing more OpenSSL callback crashes

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 choices

Re: Fixing more OpenSSL callback crashes

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

Re: Fixing more OpenSSL callback crashes

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

Re: SSL and Usability and Safety

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

Re: SSL and Usability and Safety

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

Re: SSL and Usability and Safety

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

Re: SSL and Usability and Safety

On 05/02/2017 10:32 AM, Ruediger Pluem wrote: c) would be the best, but a) IMHO would be acceptable since overwriting is for the more advanced users anyway and they can be told to do stuff in the correct order. +1 to both points. (Our conflict-merging logic in the configuration is not very

  1   2   3   4   >