Fwd: Trivial Patch for http_config.h
This is still the case in trunk. Does anyone know if this is intentional?
-- Forwarded message --
From: Joachim Zobel jzo...@heute-morgen.de
Date: Wed, Mar 21, 2007 at 4:36 PM
Subject: Trivial Patch for http_config.h
To: dev@httpd.apache.org
Hi.
This is just a typo.
Sincerely,
Joachim
--- http_config.h 2007-03-21 21:34:06.0 +0100
+++ http_config.h.fix 2007-03-21 21:32:54.0 +0100
@@ -115,7 +115,7 @@
/** method of declaring a directive with no arguments */
# define AP_INIT_NO_ARGS(directive, func, mconfig, where, help) \
-{ directive, { .no_args=func }, mconfig, where, RAW_ARGS, help }
+{ directive, { .no_args=func }, mconfig, where, AP_NO_ARGS, help }
/** method of declaring a directive with raw argument parsing */
# define AP_INIT_RAW_ARGS(directive, func, mconfig, where, help) \
{ directive, { .raw_args=func }, mconfig, where, RAW_ARGS, help }
--
Eric Covener
cove...@gmail.com
[CLOSED] Re: [VOTE] Release Apache httpd 2.4.12 as GA
The above VOTE is now CLOSED, with the result that, with sufficient +1 (binding) votes, the VOTE PASSES and the 2.4.12 tarballs will be released as GA. I will push them to the mirrors and we will likely announce tomorrow. Thx again to all testers and users of Apache httpd! On Jan 22, 2015, at 1:54 PM, Jim Jagielski j...@jagunet.com wrote: The pre-release test tarballs for Apache httpd 2.4.12 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.12 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. NOTE: The *-deps are only there for convenience. Thx!
Re: [VOTE] Release Apache httpd 2.4.12 as GA
On 1/27/15, William A. Rowe Jr. wr...@rowe-clan.net wrote: Hi Nick, Noel, I presume you are each running mod_php (and not php's fcgi sapi)? Are you doing so with prefork mpm, or the win32/worker mpm? Did you build php TS? I am running mod_php yes,prefork, and php TS. Did you update any aspect of php between your 2.4.10 and 2.4.12 test cases? On Mon, 26 Jan 2015 11:23:20 +1000 Noel Butler noel.but...@ausics.net wrote: On 25/01/2015 17:21, Nick Edwards wrote: I am noticing a number of hits using UTC with this version? Not all, only some, is anyone else seeing this? Does not occur on 2.4.10. They are php pages, however, the main site which is php is static, it only uses php for counter nothing else, its all hard written in vi. On 1/23/15, Jim Jagielski j...@jagunet.com wrote: The pre-release test tarballs for Apache httpd 2.4.12 can be found at the usual place: http://httpd.apache.org/dev/dist/ [1] I'm calling a VOTE on releasing these as Apache httpd 2.4.12 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. NOTE: The *-deps are only there for convenience. Thx! Hrmm, I also see this, 170.130.179.246 - - [26/Jan/2015:01:02:06 +] GET /archives/ 197.156.95.99 - - [26/Jan/2015:11:02:18 +1000] GET /ups/t568b.png HTTP/1.1 95.211.138.225 - - [26/Jan/2015:01:02:40 +] GET /Android-Apps.html HTTP/1.1 144.76.247.107 - - [26/Jan/2015:11:03:32 +1000] GET / (correct time is 11:xx:xx) My first thought was php - it's been known in the past to be this type of offender however I have timezone set in the ini, not to mention I've been running 5.5.20 since its release and going back a few weeks in master logs I see it only occurring since 2.4.12 was installed and I also see it on other sites, one of which is written in ruby, and a static HTML site, so that rules out php at fault (for once LOL), since only one box (my private one) is running 2.4.12, I checked a few other servers on 2.4.10 and can see no sign of this UTC logging. So, until I have time to look further I withdraw my N/B Good to go Links: -- [1] http://httpd.apache.org/dev/dist/
Re: [VOTE] Release Apache httpd 2.4.12 as GA
On Mon, 26 Jan 2015 16:43:29 -0500 Jim Jagielski j...@jagunet.com wrote: I'll give the vote another 24 hours... I don't consider the UTC/logging issue enough to hold the release, unless it appears a symptom of a more serious problem, but want to give us some more time to try to get a handle on it. I'd agree. My thoughts on OP's posts, that their specific PHP scripts are modifying the global timezone locale, notably process-by-process, and these are not reset at the end of processing. In the case of the event or worker MPM it's impossible to do this without a thread-local implementation of time.h (as Windows and Netware have long had) while even with prefork, depending on which process handles a given request, this php script will apparently have left the server in one state or another, leading to 'flipping' the timezone from log entry to entry. It's [mostly] harmless. If a given log entry is 'zinged' by a change of the timezone offset in between formatting the zone and formatting the time and the date, this could yield some wild jumps. But as the PHP crew long demoted thread saftey from experimental to deprecated (IIUC), then I'm afraid we simply have to take them at their word. The universally endorsed php processing mechanism is now fcgi. There is a possibility that OP's had actually rebuilt APR (from the -deps), even with the very same APR version, which resulting in some different autoconf detection on their platform relative to time.h function handling. It would be worth close inspection of their own config.cache files of old and new APR builds to say for sure.
Re: [VOTE] Release Apache httpd 2.4.12 as GA
Am 27.01.2015 um 21:41 schrieb William A. Rowe Jr.: On Mon, 26 Jan 2015 16:43:29 -0500 Jim Jagielski j...@jagunet.com wrote: I'll give the vote another 24 hours... I don't consider the UTC/logging issue enough to hold the release, unless it appears a symptom of a more serious problem, but want to give us some more time to try to get a handle on it. I'd agree. My thoughts on OP's posts, that their specific PHP scripts are modifying the global timezone locale, notably process-by-process, and these are not reset at the end of processing. In the case of the event or worker MPM it's impossible to do this without a thread-local implementation of time.h (as Windows and Netware have long had) while even with prefork, depending on which process handles a given request, this php script will apparently have left the server in one state or another, leading to 'flipping' the timezone from log entry to entry. It's [mostly] harmless. If a given log entry is 'zinged' by a change of the timezone offset in between formatting the zone and formatting the time and the date, this could yield some wild jumps. But as the PHP crew long demoted thread saftey from experimental to deprecated (IIUC), then I'm afraid we simply have to take them at their word. The universally endorsed php processing mechanism is now fcgi. mod_php with mpm-worker is running without threads fgci is nice, but it lacks 100% compatibility for Directory and VirtualHost settings the same way it's possible with mod_php that makes migration of many hundret virtual hosts with a ton of security specific and fine grained per-host configs a hard to undoable or at least not testable task signature.asc Description: OpenPGP digital signature
Re: [VOTE] Release Apache httpd 2.4.12 as GA
On 28/01/2015 06:41, William A. Rowe Jr. wrote: There is a possibility that OP's had actually rebuilt APR (from the -deps), even with the very same APR version, which resulting in some different autoconf detection on their platform relative to time.h function handling. It would be worth close inspection of their own config.cache files of old and new APR builds to say for sure. As I do APR|UTIL testing as well, I stay with those releases when vote passes, I dont test with -deps, since I already have them :)
Re: [VOTE] Release Apache httpd 2.4.12 as GA
Am 22.01.2015 um 19:54 schrieb Jim Jagielski: The pre-release test tarballs for Apache httpd 2.4.12 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.12 GA. [X] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. +1 to release, thanks for RMing. In short: No regressions found. Detailed report: - Sigs and hashes OK - contents of tarballs identical - contents of tag and tarballs identical except for expected deltas (we could cleanup some m4 files in apr-util/xml/expat/conftools at the end of buildconf, no regression) Built on - Solaris 8+10 Sparc as 32 Bit Binaries - SLES 10+11 (64 Bits) - RHEL 6 (64 Bits) - FreeBSD 9.1 On FreeBSD 2.4.12 runs on one machine for the ASF the www and mail-archives httpd instances. No problems showed up. For all platforms except FreeBSD built - with default (shared) and static modules - with module sets none, few, most, all, reallyall and default (always mod_privileges disabled) - using --enable-load-all-modules - against included APR/APU from deps tarball, plus external APR/APU 1.5.1/1.5.4 - using external libraries - expat 2.1.0 - pcre 8.36 - openssl 1.0.1l - lua 5.2.3 - distcache 1.5.1 - libxml2 2.9.2 - Tool chain: - platform gcc except for Solaris (gcc 4.1.2 for Solaris 8 and 4.9.1 for Solaris 10) - CFLAGS: -O2 -g -Wall -fno-strict-aliasing (and -mpcu=v9 on Solaris) All builds succeeded - two harmless compiler warnings in modules/aaa/mod_authnz_fcgi.c Fixed in r1652829 and proposed for 2.4 Tested for - Solaris 8+10 (32), SLES 11 (64), RHEL 6 (64) - MPMs prefork, worker, event (except for Solaris 8 - no event) - default (shared) and static modules - log levels info, debug and trace8 - module set reallyall (121 modules plus MPMs), all, most, few, none and default I didn't wait for finishing all combinations, but out of the about 1050 finished combinations, only the following test failures were seen: a Test 4 and 5 in t/modules/dav.t: 50 runs. Creation, modified and now times not in the correct order. This seems to be a system issue, all tests done on NFS, many tested on virtualized guests. Not a regression. b Various tests in t/apache/expr_string.t: (3, 6, 11, 14, 20 ,23) 33 runs failed this test, (all except for two on RHEL). The failure is always on line 68, where the error_log contents are checked. Not a regression. c Tests 55-57 of t/modules/cgi.t testing contents of ScriptLog. The tests fail for reallyall modules and static builds because then mod_cgi plus mod_cgid are loaded both. After r1651085 STDERR logging for mod_cgi and mod_cgid behave differently and cgi.t doesn't know which of the two loaded modules actually handles the request. This was a test suite problem. It happens on most platforms but not on Solaris 10, lilkely due to a different hook sort order of mod_cgi and mod_cgid there. We should try to port the r1651085 enhancement from mod_cgi to mod_cgid as well (logging errors to ScriptLog instead of error log in more cases). Regards, Rainer
Re: [VOTE] Release Apache httpd 2.4.12 as GA
On 1/22/2015 10:54 AM, Jim Jagielski wrote: The pre-release test tarballs for Apache httpd 2.4.12 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.12 GA. [X] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. +1, no problems seen on Windows so far. Thanks for RM.
RE: [NOTICE] Intend to TR 2.4.12 tomorrow (Thurs, Jan 22)
Hi Bill, Thanks for your comments and explanation on the procedure. If you have time, please take some time to review this patch and let me know if you see any issues. Thanks, Yingqi -Original Message- From: William A. Rowe Jr. [mailto:wr...@rowe-clan.net] Sent: Monday, January 26, 2015 10:56 AM To: Lu, Yingqi Cc: dev@httpd.apache.org Subject: Re: [NOTICE] Intend to TR 2.4.12 tomorrow (Thurs, Jan 22) On Thu, 22 Jan 2015 18:08:20 + Lu, Yingqi yingqi...@intel.com wrote: Hi Jim, Thanks for the update! A quick question on the review and testing procedure. Right now, Yann Ylavic already made available a 2.4 version of the patch. The link is included at http://svn.apache.org/r1651967 . Is this good enough or is there anything additional needed at this point? If there is no bug reported, when 2.4.13 time is approaching, the patch will automatically be on the commit list or is there anything else we need to make sure? Thanks, Yingqi -Original Message- From: Jim Jagielski [mailto:j...@jagunet.com] Sent: Thursday, January 22, 2015 9:37 AM To: dev@httpd.apache.org Subject: Re: [NOTICE] Intend to TR 2.4.12 tomorrow (Thurs, Jan 22) Since that was a very new patch, there was a risk in adding it to 2.4.11/12 since it would not have had enough time for adequate testing. It will be proposed for 2.4.13. Yingqi, a patch of this scale is generally added to the branch early, once three committers have had a chance to review it. By living on the 2.4 branch for some time (long before 2.4.13 is considered for release) we have the best chance of catching a problem between now and the release of 2.4.13. It would be just as unlikely to be added just before 2.4.13 is tagged because that doesn't give enough of the community time to review it. Yours, Bill
