Re: [Vote] httpd 2.2.18 release
On Sun. 2011-05-08 at 03:24 AM EDT, William A. Rowe Jr. wr...@rowe-clan.net wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution) will follow shortly; note that -win32-src.zip is generated from unix as a test, and if found invalid, will be rerolled. +/-1 [+1] Release httpd 2.2.18 as GA +1 checksums and signatures check no test regressions on Mac OS X 10.6.7 or Linux x86_64 Ubuntu 10.04. Dan
Removing ap_old_write_filter
I propose to remove ap_old_write_filter from trunk. I recently noticed that buffer_output(), which is apparently intended to buffer data in a brigade to be passed down the output filter chain later by ap_old_write_filter, calls the ap_fwrite() macro to do so, which always flushes the data. So no data has been getting buffered. This has been the case for at least 10 years and back to Apache 2.0.x, which is as far back as I cared to check. We could fix buffer_output() to save up the data in a brigade without flushing it, as was apparently intended, but would that break any module that has been (inadvertently) relying on buffer_output() to flush its data? Of the modules that use ap_rwrite and related APIs that end up calling buffer_output(), very few ever call ap_rflush. On the other hand, fixing the buffering might buy us some performance, as long as we're willing to fix any modules that get broken. Thoughts? Dan
Re: Removing ap_old_write_filter
On Fri. 2011-03-25 at 05:30 PM EDT, Stefan Fritsch s...@sfritsch.de wrote: Are you sure that ap_fwrite does not buffer? It calls apr_brigade_write(), which, according to the apr-util docs, should only flush if the brigade is full. You are correct. I saw the definition of ap_fwrite: #define ap_fwrite(f, bb, data, nbyte) \ apr_brigade_write(bb, ap_filter_flush, f, data, nbyte) and looking too quickly at apr_brigade_write's code, thought it always flushed when a flush function was passed to it. Thanks for the correction. Dan
Re: Why is 1.3 still on the download page?
On Mon. 2011-03-21 at 06:55 AM EDT, Malte S. Stretz m...@apache.org wrote: On Monday 21 March 2011 11:30:26 Vincent Bray wrote: On 20 March 2011 20:23, William A. Rowe Jr. wr...@rowe-clan.net wrote: I've seen no objections, and count 3 +1's to remove these, so I'm cleaning this up today. Perhaps also someone would be kind enough to remove the weekly 1.3 bugzilla summary? There are currently still 63 bugs against v1.3 [1]. I'd wade through that list, look at each bug and either (a) Close it as WONTFIX if the comments talk about v1.3.x only. (b) Change the product to httpd-2 if any comment states that it happens in v2.x, too, adding a polite reminder to retest with a non-ancient version if it wasn't updated for some time and maybe close it as NEEDINFO. Does anybody mind? +1, thanks for offering.
Re: Prior to apr 2.0 / httpd 2.4...
On Sun. 2011-03-20 at 07:47 PM EDT, William A. Rowe Jr. wr...@rowe-clan.net wrote: Nobody has offered a reasonable response, let's try this again... the availability of pcre and expat are generally a both-or-neither proposition on most distributions. Ergo, any one of the following resolutions would restore logically consistency to the next-generation distribution... [X] apr 2.0 should resume bundling expat 2.0.1 fork[1] [ ] expat helpers should be dropped from apr 2.0, while httpd should assume an ap_ interface to expat with expat distributed with httpd-deps [ ] expat helpers should be dropped from apr 2.0, in favor of direct consumption of expat 2.x by httpd, with expat distributed with httpd-deps [ ] httpd will ship expat in srclib/apr/xml in spite of apr project decisions [ ] httpd-deps should drop pcre [ ] httpd-deps should be dropped Simple majority, will re-offer this vote with the lowest vote getter dropped until we have consensus. Votes please? [1] Note particularly that expat appears to be abandoned, no releases in almost 4 yrs, with a significant security issue hanging over it we patched in apr. No effort appears to be expended in providing any alternate non-expat apr_xml interfaces. For APR to continue bundling expat seems easiest, in the absence of anyone motivated to do something more. Dan
Re: GA
On Fri. 2011-03-18 at 09:03 PM EDT, Nick Kew n...@webthing.com wrote: On 19 Mar 2011, at 00:02, Dan Poirier wrote: At some point, do we declare a feature-freeze for what will be 2.4.0? Features can be added during a release. I was just thinking of a temporary pause, that might be helpful in getting to a point where trunk is stable enough to feel comfortable declaring it 2.4.0. Maybe we don't need anything that formal. I get the sense that a few people have things they'd like to get in before 2.4.0 for some reason, but we hardly have a continuous stream of new features being added. Dan
Re: a plan mod_lua and 2.4
On Tue. 2011-03-15 at 09:08 AM EDT, Akins, Brian brian.ak...@turner.com wrote: How many people actual run mod_lua (or a derivative/relative) in production? Am I the only one on a real site? I guess the others, if any, aren't reading dev@. And searching gmane's archive of the user list only turns up a few mentions in almost 90,000 posts. Of course, it's not in a production release of the server yet. And even when 2.4.0 ships, it'll probably still be marked experimental.
Re: GA
On Fri. 2011-03-18 at 04:01 PM EDT, Jim Jagielski j...@jagunet.com wrote: My hopes are that if people are really wanting to invent and collaborate on cool stuff, that they don't wait until a f2f event that the vast majority of current httpd developers will not be attending and will instead try to start stuff now-ish in hopes of getting a GA out sooner rather than changing things so much that any momentum achieved up to now is wasted by the addition of lots of cool stuff that requires substantial vetting and thus causing yet more delays on a release that has already been long enough already thank you. At some point, do we declare a feature-freeze for what will be 2.4.0?
Re: initgroups() in mpm_common.c
On Tue. 2011-03-15 at 11:23 PM EDT, Guenter Knauf fua...@apache.org wrote:
Hi all,
I would like to get rid of a missing prototype compiler warning ...
in mpm_common.c we provide an initgroups() for platforms which dont have
that function. This function just returns 0 for _OSD_POSIX, OS2, WIN32
and NETWARE. Currently in httpd sources there are only 2 places where
initgroups() is used: mod_unixd.c and suexec.c; both will not be
compiled for at least WIN32 and NETWARE, and OS2 does #ifdef the
initgroups() calls in mod_unixd.c - so only platform where the fake stub
might be used is _OSD_POSIX (BS2000?).
One possible fix would be to avoid compiling the stub at all:
Index: server/mpm_common.c
===
--- server/mpm_common.c (revision 1082026)
+++ server/mpm_common.c (working copy)
@@ -192,10 +192,11 @@
}
#endif
+#if !defined(OS2) !defined(WIN32) !defined(NETWARE)
#ifndef HAVE_INITGROUPS
int initgroups(const char *name, gid_t basegid)
{
-#if defined(_OSD_POSIX) || defined(OS2) || defined(WIN32) ||
defined(NETWARE)
+#if defined(_OSD_POSIX)
return 0;
#else
gid_t groups[NGROUPS_MAX];
@@ -222,7 +223,8 @@
return setgroups(index, groups);
#endif
}
-#endif /* def NEED_INITGROUPS */
+#endif /* def HAVE_INITGROUPS */
+#endif
/* standard mpm configuration handling */
const char *ap_pid_fname = NULL;
another one would be to add a prototype to mpm_common.h ...
any preferences?
Gün.
The function is already wrapped in #ifndef HAVE_INITGROUPS, shouldn't
that prevent it being compiled on platforms that don't need it? If not,
that should probably be fixed (or else I misunderstand what's
happening).
Also, I'm opposed to adding more #if PLATFORM_XYZ unless we absolutely
have to.
Anyway, is there some reason why we wouldn't just add the prototype?
Dan
Re: svn commit: r1082170 - /httpd/httpd/trunk/server/main.c
On Wed. 2011-03-16 at 11:53 AM EDT, jor...@apache.org wrote: Author: jorton Date: Wed Mar 16 15:53:34 2011 New Revision: 1082170 URL: http://svn.apache.org/viewvc?rev=1082170view=rev Log: * server/main.c (main): Use the real null cleanup callback. Thanks Joe, I'd just spent the morning trying to figure out why no CGI scripts were working (they seemed to crash shortly after the fork) and this solved it. Dan
Re: a plan mod_lua and 2.4
On Mon. 2011-03-14 at 07:51 PM EDT, Brian McCallister bri...@skife.org wrote: I think the right path for this is to shrink the core mod_lua module to be the *minimal* set for integration, and pull all the higher level functionality into a non-core module, which uses the core mod_lua to hook into the server. This sounds like a good plan.
Re: a plan mod_lua and 2.4
On Tue. 2011-03-15 at 09:36 AM EDT, HyperHacker hyperhac...@gmail.com wrote: I've been eagerly looking forward to a stable mod_lua with which to make my sites. If done well, Lua could replace PHP as the #1 web scripting language Maybe if people could embed lua in web pages.
Re: a plan mod_lua and 2.4
On Tue. 2011-03-15 at 11:47 AM EDT, Jeff Trawick traw...@gmail.com wrote: On Tue, Mar 15, 2011 at 10:53 AM, Akins, Brian brian.ak...@turner.com wrote: On 3/15/11 10:05 AM, Dan Poirier poir...@pobox.com wrote: Maybe if people could embed lua in web pages. FWIW, I don't think the web needs yet another web page generator embedded inside a web server. We apps should be ran by application servers - fastcgi, proxy, etc. But that's just my opinion ;) +1 :) I agree too, but the discussion was about whether mod_lua might replace PHP some day, and I think if that's your goal (worthwhile or not) you'd have to provide web page embedding. Dan
Re: HEAD on trunk broken
I saw it yesterday on Mac OS 10.6 without XCode 4. On Thu. 2011-03-10 at 09:42 AM EST, Jim Jagielski j...@jagunet.com wrote: Not sure if anyone else is seeing this or whether this is due to my upgrade to XCode4 yesterday :/ #0 apr_global_mutex_lockfile (mutex=0x0) at locks/unix/global_mutex.c:180 180 return apr_proc_mutex_lockfile(mutex-proc_mutex); (gdb) bt #0 apr_global_mutex_lockfile (mutex=0x0) at locks/unix/global_mutex.c:180 #1 0x000100040b64 in authn_cache_child_init (p=0x10087d828, s=0x1008205d8) at mod_authn_socache.c:129 #2 0x00011e9e in ap_run_child_init (pchild=0x10087d828, s=0x1008205d8) at config.c:160 #3 0x000100118384 in child_main (child_num_arg=2) at event.c:1700 #4 0x000100118812 in make_child (s=0x1008205d8, slot=2) at event.c:1887 #5 0x000100118a47 in startup_children (number_to_start=1) at event.c:1920 #6 0x0001001193c9 in event_run (_pconf=0x100806028, plog=0x10089f828, s=0x1008205d8) at event.c:2229 #7 0x00010001a4db in ap_run_mpm (pconf=0x100806028, plog=0x10089f828, s=0x1008205d8) at mpm_common.c:90 #8 0x0001db93 in main (argc=7, argv=0x7fff5fbff2d0) at main.c:749
Re: svn commit: r1069603 - /httpd/httpd/branches/2.2.x/STATUS
On Thu. 2011-02-10 at 05:57 PM EST, wr...@apache.org wrote: Author: wrowe Date: Thu Feb 10 22:57:02 2011 New Revision: 1069603 ... * core: Add NoDecode option to AllowEncodedSlashes to turn off decoding of encoded slashes in path info. (This is already the behavior of @@ -192,11 +192,18 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: Backport version for 2.2.x of patch: http://people.apache.org/~poirier/AllowEncodedSlashes.22.patch +1 poirier, jim + +.1 wrowe; this essentially causes %2F - %2F - %252F to any backend, + as mentioned previously trunk is broken and decoding to 'something' + is necessary for routing such. %2F cannot be distinguished from + %252F on the front end, adding risks. All this said, not against + an optional broken feature if this warning is placed in the docs. + Non-optional broken features are worse :) + Trunk must be patched identically. Bill, patching trunk identically would change the behavior of AllowEncodedSlashes On in trunk from not decoding %2F to decoding %2F. Before doing that, I wanted to double-check that was the intention, and make sure nobody else objected to that behavior change in trunk. (Background for those who haven't been following along: In trunk, AllowEncodedSlashes On does not decode %2F. In 2.2.x, AllowEncodedSlashes On does decode %2F. The proposed patch to 2.2.x would add another option in 2.2.x, AllowEncodedSlashes NoDecode, which would allow the encoded slashes but not decode them.) Dan
Re: [VOTE] Release 2.3.11 as Beta
On Tue. 2011-03-01 at 12:25 PM EST, Jim Jagielski j...@jagunet.com wrote: The Apache httpd 2.3.11-beta test tarballs are available at: http://httpd.apache.org/dev/dist/ Please vote on whether to release as 2.3.11-beta. This is our first Beta release; Based on the feedback and result from this Beta, the hope is to push for a GA by the end of March (2011)! Vote will close in 72 hours. +1 Downloads good, checksums passed, signature points to Jim. Built and tested on RHEL5 ia32 with apr-1.4.2 and apr-util-1.3.10. Dan
Re: Please vote - how to handle AllowEncodedSlashes
I checked and the server accepts encoded slashes in query strings, regardless of AllowEncodedSlashes. So we're only concerned here with path info. Right now in trunk, the default is to not accept encoded slashes, and if you turn AllowEncodedSlashes on, they are not decoded. This seems safe and matches the documentation, so I don't think trunk needs to be changed (unless somebody really needs the 2.x behavior, in which case they could add an option for that, but I don't need that.) In 2.2, the default is to not accept encoded slashes, but if you turn AllowEncodedSlashes On, they are decoded. This is contrary to the documentation and the trunk behavior, and seems potentially unsafe. But just changing to the trunk behavior could break users when they upgrade between 2.2 releases, so I think the best compromise for 2.2 is to add a new option to accept the slashes without decoding them. I have a patch to do that and I'll propose it in 2.2 STATUS for the usual vote. For 2.0, I think backporting whatever is done in 2.2 can be proposed in the usual way if anyone wants it, so we don't need to discuss that here. Thanks for everyone's input on this. Dan
Re: Please vote - how to handle AllowEncodedSlashes
On 01/21/2011 01:20 PM, Dan Poirier wrote: Can we take an informal vote on how best to handle AllowEncodedSlashes? At present, AllowEncodedSlashes Off (the default) results in any request containing an encoded slash, %2F, being rejected with a 404. In 2.0 and trunk, AllowEncodedSlashes On allows the encoded slash, but does not decode it. This keeps httpd from misinterpreting an encoded slash in a request as a path separator. I believe this was always the intended behavior. In 2.2, AllowEncodedSlashes On allows the encoded slash, and decodes it. This has caused problems for multiple people (see bugzilla, e.g. PR 35256), but has been the behavior since 2.2.0 (introduced in 2.1.something, I believe unintentionally). One correction for the record - 2.0 behaves like 2.2. I doubt it's worth fixing, though.
Re: Please vote - how to handle AllowEncodedSlashes
On Sun. 2011-01-23 at 12:25 PM EST, Stefan Fritsch s...@sfritsch.de wrote: On Sat, 22 Jan 2011, Ruediger Pluem wrote: How to handle? [ ] 1. change the 2.2 doc to reflect the actual 2.2 behavior [ ] 2. backport the trunk behavior as-is, so 2.0/2.2/trunk behave the same [ ] 3. backport the trunk behavior, but using a new option to avoid breaking existing configurations that might depend on the current behavior [X] 4. backport the trunk behavior, but using a new option to set the current 2.2 behavior to avoid breaking existing configurations from 2.0/trunk but enable 2.2 users that rely on the new 2.2 behavior to get this back +1. AIUI, this is the same as on/off/decode in Bill's proposal. Right, I think we have two new choices added to my original list: [ ] 4. change AllowEncodedSlashes On in 2.2 to match the 2.0/trunk behavior, but add a new option (Decode) that would behave like AllowEncodedSlashes On in 2.2 behaves now. [ ] 5. Choice 4, and add another new option to specify what %2F should decode to. (Maybe this would be an optional parameter to Decode rather than a separate option.) To my mind, (4) has the drawback of possibly breaking people who do a minor upgrade from 2.2.x to 2.2.x+1. But it could only break people who have the non-default AllowEncodedSlashes On configured - I wonder how common that is? Note that we could do (3) or (4) now, and add (5) later. Bill would like (5) to provide a way to specify Unicode strings. I'm fine with that, but if we do, perhaps we should consider providing that in a more general form than just for this directive? (Maybe that's what Bill is proposing?) Dan
Please vote - how to handle AllowEncodedSlashes
Can we take an informal vote on how best to handle AllowEncodedSlashes? At present, AllowEncodedSlashes Off (the default) results in any request containing an encoded slash, %2F, being rejected with a 404. In 2.0 and trunk, AllowEncodedSlashes On allows the encoded slash, but does not decode it. This keeps httpd from misinterpreting an encoded slash in a request as a path separator. I believe this was always the intended behavior. In 2.2, AllowEncodedSlashes On allows the encoded slash, and decodes it. This has caused problems for multiple people (see bugzilla, e.g. PR 35256), but has been the behavior since 2.2.0 (introduced in 2.1.something, I believe unintentionally). All the doc, even in 2.2, reflects the 2.0/trunk behavior. How to handle? [ ] 1. change the 2.2 doc to reflect the actual 2.2 behavior [ ] 2. backport the trunk behavior as-is, so 2.0/2.2/trunk behave the same [ ] 3. backport the trunk behavior, but using a new option to avoid breaking existing configurations that might depend on the current behavior Thanks, Dan
Re: Apache httpd 2.3.10-alpha pretest tarballs....
On Mon. 2010-12-13 at 11:03 AM EST, Jim Jagielski j...@jagunet.com wrote: The Apache httpd 2.3.10-alpha pre-test tarballs are available at: http://people.apache.org/~jim/httpd-2.3.10-alpha Please do a quick sanity check before I call for an official vote. Looks okay on Mac 10.6.4 built 32-bit. 64-bit still has %ld problems, but that's not a regression. Dan
Re: ditch NameVirtualHost directive?
On Wed, Dec 8, 2010 at 12:07 PM, Eric Covener cove...@gmail.com wrote: ... and assume overlaps are intentional opt-in to name-based vhosts? The selection algorithm would not change, meaning you'd still only be selecting from the best ip-based match. We'd lose the warning about overlapping vhosts, and maybe incur some overhead on mapping a vhost that was unintentionally showing up multiple times. Just kicking the idea around since NVH seems to be tough for users to grok. +1. Makes sense. -- Dan Poirier poir...@pobox.com
Re: rotatelogs: support for echoing to stdout
On Fri, Dec 3, 2010 at 7:47 PM, Graham Leggett minf...@sharp.fm wrote: When processing logs in real time by more than one tool, it is useful for rotatelogs to optionally pass logs through to stdout for further processing by the next tool in the chain using reliable piped logs. This patch makes this possible. Maybe add an error message to explain why rotatelogs suddenly exited if the write fails, but otherwise looks fine to me. -- Dan Poirier poir...@pobox.com
Re: disk cache file rename errors on Windows
Is anyone successfully using mod_disk_cache on Windows? Thanks, Dan
Re: disk cache file rename errors on Windows
On Thu, Dec 2, 2010 at 12:23 PM, Graham Leggett minf...@sharp.fm wrote: On 23 Nov 2010, at 8:21 PM, Dan Poirier wrote: We're seeing errors like this from mod_disk_cache on Windows only: (OS 5)Access is denied. : disk_cache: rename tempfile to datafile failed: c:/temp/HTTPServer7/aptmpV0JKJ8 - c:/temp/HTTPServer7/wHY/FhW/b...@muvttlk@V4w.data under moderate to heavy load, resulting in requests failing. Looking at the code, the error message is thrown when apr_file_rename() fails, specifically when a temporary file is swung into place in the cache. Looking at the APR code, there is a forest of ifdefs that seem to choose one of MoveFileEx(), MoveFileW(), MoveFileExW() or MoveFile(). Ideally, the Microsoft API documentation should explain under what conditions the error Access is denied is thrown. Does Windows allow you to move a file into place while the replaced file is still open for read? Disclaimer: My last real Windows programming was on WfW 3.11, so please, someone with up-to-date Windows programming experience correct me as needed. From the doc for MoveFileEx (http://msdn.microsoft.com/en-us/library/aa365240%28VS.85%29.aspx), you can pass a flag telling Windows to do the move on the next reboot (also see http://support.microsoft.com/kb/140570) , apparently to work around an inability to rename another file over a file in use. So I think the answer to your question is no. The doc for error 0x05 at http://msdn.microsoft.com/en-us/library/ms681382%28v=VS.85%29.aspx consists, in its entirety, of Access is denied.. Maybe there's more explanation elsewhere. -- Dan Poirier poir...@pobox.com
disk cache file rename errors on Windows
We're seeing errors like this from mod_disk_cache on Windows only: (OS 5)Access is denied. : disk_cache: rename tempfile to datafile failed: c:/temp/HTTPServer7/aptmpV0JKJ8 - c:/temp/HTTPServer7/wHY/FhW/b...@muvttlk@V4w.data under moderate to heavy load, resulting in requests failing. This is with Apache 2.2.8, but reproducible under 2.2.17 as well. With 2.2.17, enabling the cache lock changes the errors to failures stat'ing the lock files, but we still get errors. Bug 39216 might be related, but applying that patch didn't solve the problem, or at least, not completely. It's a little hard to reproduce reliably, so it's hard to tell if the patch helped, but we definitely still see errors. I suspect this is due to other threads having the files open at the same time, but don't have any real evidence of that other than the error we're seeing. Any ideas about solving this problem? Thanks, Dan
Any standard on picking a response status out of several possible?
If multiple response statuses would be valid for a request (e.g. 403, 413), is there any standard on how to pick one? I looked through RFC 2616 but didn't see anything. Or is it just an implementation detail? Thanks, Dan
Re: [RFC] Error directive to generate custom error messages from httpd.conf
Cute. Always nice to have better error reporting.
Re: [RFC] Error directive to generate custom error messages from httpd.conf
On Sun. 2010-11-07 at 08:29 PM EST, Sander Temme scte...@apache.org wrote: Pardon my rust, but what actually makes the process error out? Returning !nil? Right, config handlers either return NULL or an error message, and that fails startup.
Re: ap_expr problems
On Thu. 2010-11-04 at 06:39 PM EDT, Stefan Fritsch s...@sfritsch.de wrote: On Thursday 04 November 2010, Dan Poirier wrote: Before we invent yet another expression language, should we consider using something that already exists? E.g. lua? Do you want to make lua a requirement for httpd core? Is lua available for all plattforms that httpd runs on? Is lua fast enough for being used in e.g. mod_filter and mod_headers? I don't know, maybe someone else can answer these. And it doesn't have to be lua, that was just the first thing that occurred to me. We already have two expression languages in httpd (three if you count RewriteCond). One is in mod_ssl and one in mod_include. We can drop neither for backward compatibility. I think that mod_ssl's parser is much better suited as a general purpose tool than mod_include's parser. Must we maintain backward compatibility in 2.4? 3.0? How long do we maintain backward compatibility when moving to a common expression format would make the whole configuration more understandable in the long term?
Re: Feedback for new ap_expr wanted
On Fri. 2010-11-05 at 03:26 PM EDT, Stefan Fritsch s...@sfritsch.de wrote: Hi, I have put the current state of my work on ap_expr here and would welcome feedback: http://people.apache.org/~sf/ap_expr_ng_v0/ Very cool! Even has tests. There are definitely some things left to do, like implementing regexp backreferences and splitting util_expr_eval.c into several files. But I think the current state may be already good enough for trunk. +1. Eager to play with it. Dan
Re: ap_expr problems
Before we invent yet another expression language, should we consider using something that already exists? E.g. lua? Dan
Re: Why AllowEncodedSlashes config not merged?
Actually, from https://issues.apache.org/bugzilla/show_bug.cgi?id=35256, it appears AllowEncodedSlashes hasn't worked right for some time, so there doesn't seem much point in fixing its config merging. Given the discussion in that bug, I'm wondering if AllowEncodedSlashes should just be deprecated or removed entirely. Thoughts? Dan
Re: mod_include: include virtual and error handling
As long as the default behavior continues unchanged, it seems harmless. I just wonder how many users would find a use for it? I assume you have a use case in mind? Dan
Questions before I add .n feature to rotatelogs
I'm working on a keep-N-files feature for rotatelogs (rename logfile to logfile.1, logfile.1 to logfile.2, etc up to N) but have a couple of concerns before I commit it. 1) Is it safe to rename an open file on all platforms? I know Unix is okay, and testing on Windows 2003 worked, but I'm not sure about older Windows, NetWare, etc. 2) All the current schemes have the nice property that rotatelogs can try to open the new logfile before closing the old one, so if the open fails, it can truncate and re-use the still-open old logfile. If I can't rename the old file before closing it, I'll have to close it and rename it before opening the new one, since the new one will have the same name. Is that much of a concern? Thanks, Dan
Why AllowEncodedSlashes config not merged?
Is there some subtle reason why config merging isn't implemented for AllowEncodedSlashes? Thanks, Dan
Re: svn commit: r1029814 - in /httpd/httpd/trunk/modules: cache/config.m4 core/config.m4 dav/fs/config6.m4 dav/lock/config6.m4 dav/main/config5.m4 debugging/config.m4 filters/config.m4 generators/conf
On Mon. 2010-11-01 at 06:51 PM EDT, Jeff Trawick traw...@gmail.com wrote: On Mon, Nov 1, 2010 at 4:02 PM, poir...@apache.org wrote: Author: poirier Date: Mon Nov 1 20:02:51 2010 New Revision: 1029814 URL: http://svn.apache.org/viewvc?rev=1029814view=rev Log: Add to modules' help text (displayed by ./configure -h) more information that will be useful in deciding whether to enable them or not. -APACHE_MODULE(bucketeer, buckets manipulation filter, , , no) -APACHE_MODULE(dumpio, I/O dump filter, , , most) +APACHE_MODULE(bucketeer, buckets manipulation filter. Useful only for developers and testing purposes., , , no) +APACHE_MODULE(dumpio, I/O dump filter. Useful only for developers and testing purposes., , , most) mod_dumpio is used by end users to collect doc for problem diagnosis. Thanks, I backed that one out.
Re: Why AllowEncodedSlashes config not merged?
On Mon. 2010-11-01 at 06:47 PM EDT, Jeff Trawick traw...@gmail.com wrote: On Mon, Nov 1, 2010 at 5:37 PM, Dan Poirier poir...@pobox.com wrote: Is there some subtle reason why config merging isn't implemented for AllowEncodedSlashes? http://svn.apache.org/viewvc?view=revisionrevision=98479 I guess oversight. Okay, it also looks like it should be changed from RSRC_CONF to OR_FILEINFO, given that it's stored in the directory context. That does open it to .htaccess if AllowOverride FileInfo is in effect. Complete change looks like: http://people.apache.org/~poirier/allow_encoded_slashes.diff
Apachecon hackathon?
To participate in the hackathon, do we just show up Monday morning? (If so, when and where?) Or is there a signup or something? (I'm attending Apachecon for the first time next week, and can't find any information on the Apachecon web site or httpd wiki about this.) Thanks, Dan
Re: [PATCH] How to Use strcmp to Check for Equality Without Confusing Your Fellow Code, Or: Isn't There a Macro for That?
On 2010-10-19 at 15:21, Roy T. Fielding field...@gbiv.com wrote: On Oct 19, 2010, at 9:36 AM, Malte S. Stretz wrote: And there are a lot of string compares in the Apache codebase. Everytime you see a strcmp, you (or is it only me?) have to stop and think well, is this branch checking for equality or the opposite? I think this is a case where either a coding standard could help, or some helper macros in APR. I went for the latter and defined APR_EQ plus variants in apr_string.h. See attached patch. Maybe a standard would help. More macros would not -- that pain would be far worse than the current inconsistency. -1 (design opinion, not veto) I tend to agree with that. Writing our code in C in a consistent way that will become very familiar to Apache developers and is easy to interpret by anyone else who's already familiar with C is better than trying to use macros to hide it, and thus making it unfamiliar to everyone. Is there a commonly accepted usual way of writing this that we could adopt without getting into a long discussion of the relative merits of every possibility? Dan
Re: mod_cache: store_body() bites off more than it can chew
On 2010-09-06 at 05:52, Niklas Edmundsson ni...@acc.umu.se wrote: On Fri, 3 Sep 2010, Graham Leggett wrote: Been keen to do this for a while, this would definitely solve the RAM problem, but wouldn't solve the time problem. Copying 4GB of data from a slow disk can easily take minutes, and when Blu-ray images start becoming common, the problem would get worse. Yup. The next step to solve that would be to be able to serve requests from cache while they are being cached. I don't know the RFC implications of doing this, but in real life it's really useful. That would be cool. If two requests come in for the same 4GB resource close together, it's a shame to to have to retrieve it twice.
caching partial repsonses
On 2010-07-11 at 01:40, n...@apache.org wrote: Author: niq Date: Sun Jul 11 05:40:27 2010 New Revision: 962985 * mod_disk_cache: Decline the opportunity to cache if the response is a 206 Partial Content. This stops a reverse proxied partial response @@ -214,6 +225,9 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: Trunk patch: http://svn.apache.org/viewvc?rev=951222view=rev 2.2.x patch: http://people.apache.org/~minfrin/httpd-cache-partial-2.2.patch +1: minfrin +niq asks: I can see the logic of not cacheing partial responses, +but why should mod_disk_cache worry about them if mod_cache allows +them, as in the following proposal? *) mod_cache: Explicitly allow cache implementations to cache a 206 Partial Response if they so choose to do so. Previously an attempt to cache a 206 I think right now mod_cache doesn't let any 206 responses get to the cache backends, but if that change is made to let them by, then backends that don't correctly implement caching of 206 responses will need to decline to cache them themselves. Which makes me wonder, won't other cache back-ends, like mod_mem_cache, need the same change? Dan
Re: caching partial repsonses
On 2010-09-02 at 12:37, Ruediger Pluem rpl...@apache.org wrote: On 09/02/2010 04:09 PM, Dan Poirier wrote: On 2010-07-11 at 01:40, n...@apache.org wrote: Author: niq Date: Sun Jul 11 05:40:27 2010 New Revision: 962985 * mod_disk_cache: Decline the opportunity to cache if the response is a 206 Partial Content. This stops a reverse proxied partial response @@ -214,6 +225,9 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: Trunk patch: http://svn.apache.org/viewvc?rev=951222view=rev 2.2.x patch: http://people.apache.org/~minfrin/httpd-cache-partial-2.2.patch +1: minfrin +niq asks: I can see the logic of not cacheing partial responses, +but why should mod_disk_cache worry about them if mod_cache allows +them, as in the following proposal? *) mod_cache: Explicitly allow cache implementations to cache a 206 Partial Response if they so choose to do so. Previously an attempt to cache a 206 I think right now mod_cache doesn't let any 206 responses get to the cache backends, but if that change is made to let them by, then backends that don't correctly implement caching of 206 responses will need to decline to cache them themselves. Which makes me wonder, won't other cache back-ends, like mod_mem_cache, need the same change? Exactly, but mod_mem_cache is not on trunk any longer. So we cannot do a backport here, but must write a 2.2.x specific patch that is not on trunk. True, but I think that's needed before we can backport the mod_cache change being proposed here. Dan
Re: AP_REG_* compile flags
On 2010-08-06 at 09:58, Nick Kew n...@webthing.com wrote: Our code supports two regexp flags: AP_REG_ICASE and AP_REG_NEWLINE. Our documentation and widespread usage include not just these, but also AP_REG_EXTENDED and AP_REG_NOSUB, which are ignored in util_pcre. I presume the unused flags are a historic legacy and can usefully be removed from the docs. But I wonder if they should also be expunged from trunk ap_regex.h, to clean up the legacy? +1. If they're not implemented, clean 'em out.
_default_ and * in vhost hostnames
Suppose we just make _default_ a synonym of * in virtual host hostnames? Eric brought this up a while back, with little response at the time. Right now, you can only use * in the hostname of a name-based virtual host, and only use _default_ in the hostname of an IP-based virtual host. Their meanings are similar already, and any subtle differences in how we've defined them aren't really relevant, since you can't use both in the same virtual host anyway, so there's never any need to distinguish them. So, I'm proposing we simplify the code, and documentation, by making _default_ just another name for *, and maybe if we see _default_, issuing a warning that its use is deprecated. Thoughts? Dan
Failing startup for vhost configuration problems
I'd like to propose that in 2.3/2.4, we fail startup for any of the virtual host misconfigurations for which behavior is undefined but right now we only issue a warning. E.g. no VirtualHosts matching a NameVirtualHost, overlapping VirtualHosts, use of _default_ in NameVirtualHost, mixing * and non-* ports in name-based virtual hosts. The rationale is that these configurations are unsupported, the behavior is undefined, and presumably they are the result of errors, so better to make sure the admin corrects the error than to continue and probably not behave as the admin expects. A new major version seems like a good time for a change like this. Thoughts? Dan
Re: Error log format configuration syntax
On 2010-07-28 at 03:51, Alex Wulms alex.wu...@scarlet.be wrote: Hi, While adding some debug log statements to a module I'm working on, I ran into the problem that ap_log_error (in apache 2.2) does not support %zd or %zu conversion for type_t arguments. This was problematic to make the code compile on both 32 and 64 bit platforms. * platform (32-bit or 64-bit). This violates the whole purpose of type_t, which * was introduced in C exactly to provide cross-platform compatibility... I'm confused. Neither c89 nor c99 define a type type_t, as far as I can see. But you might find the *_FMT macro definitions from APR helpful, or else explain your problem in more detail? Dan
Re: Untainting an incoming request
Example usage? Just to better understand the scope, can this do things that one couldn't do (however painfully) with mod_rewrite? Dan
Re: [VOTE] Release httpd 2.2.16
Non-binding +1 Builds tests with no regressions on Linux RHEL5 x86
2.2.16 RC - pr17629.t failure on Linux
Relatively new test pr17629.t seems to be failing for me on Linux: # expected: begin-foobar-end # received: !!!ERROR!!! not ok 4 # Failed test 4 in t/apache/pr17629.t at line 47 Failed 1/4 subtests In the error log: [Thu Jul 22 09:52:45 2010] [debug] mod_echo_post.c(48): [client 127.0.0.1] [mod_echo_post] going to echo 37 bytes [Thu Jul 22 09:52:45 2010] [debug] mod_echo_post.c(63): [client 127.0.0.1] [mod_echo_post] ap_get_client_block got error [Thu Jul 22 09:52:45 2010] [debug] mod_echo_post.c(67): [client 127.0.0.1] [mod_echo_post] done reading 0 bytes, 37 bytes remain ap_get_client_block doesn't provide any more detail on why it fails. Just me? Any suggestions on further debugging? Thanks, Dan
Re: 2.2.16 RC - pr17629.t failure on Linux
On 2010-07-22 at 10:32, Plüm, Rüdiger, VF-Group ruediger.pl...@vodafone.com wrote: -Original Message- From: Dan Poirier [mailto:poir...@pobox.com] Sent: Donnerstag, 22. Juli 2010 16:21 To: dev@httpd.apache.org Subject: 2.2.16 RC - pr17629.t failure on Linux This is no regression but due to a backport that missed the boat for 2.2.16. See the STATUS file of 2.2.x and search for 17629. That would explain pr43939.t also, thanks. What about these? t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1) Failed test: 2 t/ssl/require.t (Wstat: 0 Tests: 8 Failed: 1) Failed test: 7 I don't see any SSL-related proposed backports in STATUS that could explain these. Dan
Re: Module build defaults for trunk
On 2010-06-21 at 14:32, Stefan Fritsch s...@sfritsch.de wrote: On Monday 21 June 2010, Dan Poirier wrote: But is there any reason why we couldn't just make all actually build all? And I would suggest if there's not a really good reason, we should just fix all to do what it obviously should. That should be easy now, just delete the current all and rename the new reallyall to all. I would prefer all to be everything except those modules that are only useful for developers: ... BTW, is there a better name for reallyall that makes clear that it is geared towards developers? I thought lint (suggested by someone on the list) didn't sound descriptive enough to me. But maybe it's still better than reallyall. If that's the motivation, how about maintainer, since we already have --enable-maintainer-mode? Dan
Re: Module build defaults for trunk
On 2010-06-10 at 16:46, Stefan Fritsch s...@sfritsch.de wrote: On Monday 07 June 2010, Rainer Jung wrote: - build most module set by default. Alternatives are: - all - few (same set as was default before the change) - none I would like to have an option for developers/testers that builds every module that can be built with the currently installed libraries. The attached patch adds a reallyall set. My auto-fu could be better but the patch works for me (tm). Of course, I am open for better names than reallyall. Seems to work for me. But is there any reason why we couldn't just make all actually build all? And I would suggest if there's not a really good reason, we should just fix all to do what it obviously should. That should be easy now, just delete the current all and rename the new reallyall to all. Dan
Re: Reminder about an empty docs page
On 2010-06-11 at 11:07, William A. Rowe Jr. wr...@rowe-clan.net wrote: Who wants to take on http://httpd.apache.org/docs/trunk/upgrading.html so that we can increase alpha adoption? With the sectional authnz changes, this document really needs to be filled in. I took a first pass at it, but I think it could really use a more extensive section on how to change configurations that use the 2.2 auth directives to use the new 2.4 system.
Re: server-status-handler information leak
On 2010-06-11 at 08:39, Volker g...@schwicking.de wrote: Hi, while playing around with handlers, i noticed, that any user can register the 'server-status'-handler by putting SetHandler server-status in an htacces-File. This can not be prevented by using a alternating AllowOverride-directives, since 'SetHandler' is part of 'FileInfo' which also holds ErrorDocuments, mod_rewrite, etc. Since the server-status-handler offers information one might not want others to have access to (for example a massive shared hosting environment), i created a small patch that enables a custom handlername for the server-status-module. Just thought someone else might have use for it. What this patch does: - reserves memory for directive with parameter (AP_INIT_TAKE1) - adds a function for creating config-records (create_modstatus_config) - adds a function to set the handlername (set_serverstatus_handler_name) If the handlername is not set using the directive, it defaults to the old 'server-status' and continues to work with the old setting. ... Any comments, suggestions, improvements and/or critical comments are welcome. Thanks for the problem report and patch. Since it doesn't seem that anyone has responded yet (unless I missed it), I suggest that you open a bug report and attach your patch there so it's not forgotten. I keep thinking there ought to be a better solution for this, but I can't think of one so far. Dan
Re: [VOTE] Release httpd 2.3.6-alpha
+1: Non-binding and missed the deadline, but for what it's worth... Downloads okay, md5 sha checksums good. Built on Mac OS 10.6.3 with CC='gcc -arch i386' Test framework passes except for SSL, I think I would need to track down a more recent OpenSSL than Mac OS 10.6.3 provides to get the session renegotiation stuff to work.
Re: C as config
On 2010-06-07 at 17:42, Akins, Brian brian.ak...@turner.com wrote: On 6/7/10 9:16 AM, Dan Poirier poir...@pobox.com wrote: Did you profile httpd? I'm wondering if you had a few non-trivial hooks in lua, if it would be a significant part of the CPU consumption, or would it be swamped by the rest of the processing that always goes on for a request? Increasingly, httpd is just there to provide a base to run Lua stuff for us. You'd be surprised how easily problems get solved with a few if's and else's instead of mounds of rewrite rules. Not really :-) I'm a huge fan of general-purpose scripting languages whenever possible. At normal load it doesn't really matter - the trade off is worth it (speed vs simplicity). However, as the servers get more and more loaded, Lua takes a rather large percentage of the CPU. And it's the Lua stuff not the part that does work. The constant string hashing, metatable lookups, etc. That's a shame. I wonder if another embedded language would do better? E.g. mod_perl, mod_python? They've both been around for a while. I wonder why neither has gotten into the server? Dan
Re: C as config
On 2010-06-04 at 18:21, Akins, Brian brian.ak...@turner.com wrote: Also, I do a good bit with Lua -- in httpd and other projects. Every time I run profiles on this stuff, Lua is always 3 out of the top 5 cpu consumers. And lots of it is just the language itself (all the table look-ups) and we highly optimized our method dispatches (using apr_hash, even had a version using gperf). Now this is probably just fine for mere mortals, but it has always bothered me. We always meant to go back and write higher level modules based on the low level Lua bindings, but we never did and we have several non programmers who are happily writing configs in Lua. Did you profile httpd? I'm wondering if you had a few non-trivial hooks in lua, if it would be a significant part of the CPU consumption, or would it be swamped by the rest of the processing that always goes on for a request?
Re: What's next for 2.2 and 2.3/trunk?
On 2010-06-03 at 22:28, William A. Rowe Jr. wr...@rowe-clan.net wrote: Not because of binary compatibility, but because users have certain expectations when they move from x.y.15 to x.y.16 that nothing much has changed, it's just lots of fixes. And if your backport ideas include a lot of config changes, well that further breaks the users expectations. Absolutely. We can't be making changes in 2.2.x that break existing configurations. Dan
Re: STATUS: * RFC 2616 violations.
On 2010-06-04 at 06:00, Igor Galić i.ga...@brainsware.org wrote: Hey folks, I've gone through the list of RFC violation PRs in the STATUS file and here's the summary: Thanks for doing this.
Re: Reducing number of mod_lua hook directives
You could go even farther, and just provide a way to run some Lua code at startup, and provide Lua APIs to add hooks, handlers, or whatever else you wanted. But while as a programmer that sounds fine to me, I suspect for the average user who just wants to add a few lines to tweak something, quite possibly copying the configuration from a web site or a book, it's easier if we provide a bit more of a framework for them. Of course, the two options aren't mutually exclusive.
Re: Reducing number of mod_lua hook directives
On 2010-05-10 at 16:03, William A. Rowe Jr. wr...@rowe-clan.net wrote:
On 5/10/2010 2:25 PM, Brian McCallister wrote:
...
to
LuaHook AccessChecker /path/to/script.lua funcname
LuaHook AuthChecker /path/to/script.lua funcname
LuaHook CheckUserID /path/to/script.lua funcname
Any reason not to name the func before the script, especially since path names
can get long winded, and I'm thinking C like decl funcname(args) {script}
So we'd have
LuaHook AccessChecker funcname /path/to/script.lua
and (unchanged)
LuaHook AccessChecker funcname
which makes the two forms more consistent too. Sounds fine to me.
Dan
Re: Reducing number of mod_lua hook directives
On 2010-05-11 at 08:52, Dan Poirier poir...@pobox.com wrote:
On 2010-05-10 at 16:03, William A. Rowe Jr. wr...@rowe-clan.net wrote:
On 5/10/2010 2:25 PM, Brian McCallister wrote:
...
to
LuaHook AccessChecker /path/to/script.lua funcname
LuaHook AuthChecker /path/to/script.lua funcname
LuaHook CheckUserID /path/to/script.lua funcname
Any reason not to name the func before the script, especially since path
names
can get long winded, and I'm thinking C like decl funcname(args) {script}
So we'd have
LuaHook AccessChecker funcname /path/to/script.lua
LuaHook AccessChecker funcname
I just thought of a problem - right now, the funcname is optional
(defaults to handle). I hate having optional arguments that don't
come at the end. I'd just as soon make it a required argument, but if
people would rather it stay optional, then I'd rather leave it at the
end. What do folks prefer?
Dan
Re: Reducing number of mod_lua hook directives
On 2010-05-11 at 12:55, HyperHacker hyperhac...@gmail.com wrote: On Tue, May 11, 2010 at 08:47, Dan Poirier poir...@pobox.com wrote: I just thought of a problem - right now, the funcname is optional (defaults to handle). I hate having optional arguments that don't come at the end. I'd just as soon make it a required argument, but if people would rather it stay optional, then I'd rather leave it at the end. What do folks prefer? I'd go for making it required, but is there a reason you have to specify a function? Lua scripts usually start executing from the first line in the file. It seems to me to make more sense to do that if a function is not specified (or is - if it's a required argument). The request object is passed to the function as an argument, so there would have to be some other way to give the Lua code access to the request.
Re: Reducing number of mod_lua hook directives
On 2010-05-11 at 12:59, Akins, Brian brian.ak...@turner.com wrote: The hook runner itself should just be in lua. Instead of scripts, you write lua modules. If a lua module has a function with the correct names (ie, same as hooks) it uses that: Ie in my module foo function fixups( r ) Would get called at fixups, etc. No need for a state per file, etc. Just have one state per thread. That sounds like a bigger change to how everything works. So we'd just associate a Lua module with a configuration context, then any functions defined in that module with names the same as hooks would get invoked in those request phases? Even if we don't go that far, I like the idea of just naming the functions the same as the hooks, and not cluttering the configuration with function names that most people will probably make the same as the hook names anyway. Maybe we should just drop the function names from the configuration.
Reducing number of mod_lua hook directives
mod_lua has 8 separate directives for adding hooks using external files with Lua code (LuaHookX) and 8 more for adding the same hooks using inline Lua code (LuaHookX). Most of the code to implement these is common. I think it'd be easier to understand - and document - the module if we cut these down to two directives, with an additional argument to indicate which hook is involved. E.g. change LuaHookAccessChecker /path/to/script.lua funcname LuaHookAuthChecker /path/to/script.lua funcname LuaHookCheckUserID /path/to/script.lua funcname ... to LuaHook AccessChecker /path/to/script.lua funcname LuaHook AuthChecker /path/to/script.lua funcname LuaHook CheckUserID /path/to/script.lua funcname ... and LuaHookAccessChecker funcname -- lua code /LuaHookAccessChecker to LuaHook AccessChecker funcname -- lua code /LuaHook Thoughts? Dan
Re: perl 5.12 / mod_perl
On 2010-05-06 at 09:06, Jeff Trawick traw...@gmail.com wrote:
On Thu, May 6, 2010 at 8:48 AM, tech_list tech_l...@womenshealth.comwrote:
Thanks!
Line 96:
if ($pos = $[) { if ($pos = 0) {
I think this should be changed back. It is only assignment of $[ that is
deprecated, correct?
My 2cents: If you don't assign to $[ then $[ must be 0 in this Perl source
file. And comparing with 0 instead of $[ is understandable to more people.
Agreed, there's no reason to even mention $[ in current Perl code.
Adding origin of abort to connection structure
I was looking at https://issues.apache.org/bugzilla/show_bug.cgi?id=48301 which asks for a way to distinguish in the log whether a connection was aborted by the web server or the other end. To do that, we'd need to note the cause of the abort in the connection structure. I was hoping to just use another non-zero value for connect-abort, but it turns out that connect-abort is a 1-bit field. In trunk we could just expand that field, or add another field. But is there a way we could add this feature in 2.2 without breaking the API?
Re: Adding origin of abort to connection structure
On 2010-05-03 at 14:23, Jeff Trawick traw...@gmail.com wrote: On Mon, May 3, 2010 at 2:16 PM, Dan Poirier poir...@pobox.com wrote: I was looking at https://issues.apache.org/bugzilla/show_bug.cgi?id=48301 which asks for a way to distinguish in the log whether a connection was aborted by the web server or the other end. To do that, we'd need to note the cause of the abort in the connection structure. Help me understand what server-aborted connection means, at least for connections that the web server is aware of. I guess it is a server-aborted connection when the server closes before the client during lingering close. If the server encounters an I/O error writing to the client it is assumed to be client-aborted, but the client may not see it that way. That's a really good question. mod_dav will abort if it runs into an error part-way through returning a multi-part response. mod_ssl will abort if it can't set up an SSL connection. Otherwise, it looks like setting c-aborted mostly happens when we get an error on a connection, which isn't really server-aborted. But I'm not sure if that's what the bug reporter had in mind. I'll followup there. Dan
Re: IDE for Apache HTTP server development?
On 2010-05-01 at 09:35, Nicholas Sherlock n.sherl...@gmail.com wrote: On 1/05/2010 1:43 a.m., Dan Poirier wrote: Does anyone have recommendations for an IDE they use for development on the server? Preferably that runs on Mac, or else Linux. I haven't been a big fan of IDEs, being happy with Emacs for years, but I've found for Java development, I'm clearly more productive in Eclipse than Emacs. Eclipse has CDT, the C/C++ Development Tooling, have you tried that out? Yes, I should have said. I tried for a while to get APR to build in Eclipse, figuring that was a prerequisite for building HTTPD, but never managed it. If someone has, I'd love to see their Eclipse project and other configuration files. Dan
Re: Stop accepting PRs for 1.3?
On 2010-04-29 at 23:13, Sander Temme scte...@apache.org wrote: Crowd, Since we have released our last release, how about we close the Apache httpd-1.3 product in Bugzilla for entering new bugs? Say the word and I'll click the clicky in the Bugzilla admin. +1 (not binding) If we do, we should do the same when we release the final version of 2.0, and mention it in the announcement. Dan
Re: Stop accepting PRs for 1.3?
On 2010-04-30 at 08:38, Jeff Trawick traw...@gmail.com wrote: On Fri, Apr 30, 2010 at 8:12 AM, Plüm, Rüdiger, VF-Group ruediger.pl...@vodafone.com wrote: +0.5 I am a little bit undecided as it might be still a useful forum for users to share bugs and patches for them with other users alltough the won't get fixed / applied by us anymore. same general concern here: some community will still use httpd 1.3, and IMO we don't want to further separate them from the modern-httpd crowd Whether or not the bug db is closed to 1.3, we should doc on the front page what we provide in support of the 1.3 community: insert please-use-latest-version caveat * 1.3 discussions welcome on user mailing list * users welcome to share 1.3 howtos/workarounds on the Httpd Wiki (subject to general policies of the wiki) * security reports on 1.3 accepted and analyzed on secur...@apache.org; any resulting approved patches maintained in patches/apply_to_1.3... directory * possibly: users share problem reports/patches in the bug db My concern is that people will submit 1.3 bug reports, and get frustrated when there's no official response. Is there a way we can keep 1.3 submissions open but make the level of support for 1.3 clear to bug submitters? Dan
IDE for Apache HTTP server development?
Does anyone have recommendations for an IDE they use for development on the server? Preferably that runs on Mac, or else Linux. I haven't been a big fan of IDEs, being happy with Emacs for years, but I've found for Java development, I'm clearly more productive in Eclipse than Emacs. So I'm wondering if I'm missing something similar that could be used when I work on Apache. Thanks, Dan
Re: [Survey] Maintained builds - was Re: httpd trunk, apr/apu 1.4 branches and Linux
On 2010-04-25 at 12:07, William A. Rowe Jr. wr...@rowe-clan.net wrote: You raise interesting questions about what the httpd folks actually test on a day to day basis, given the dozen combinations of build approaches. Maintainers, which of the below do you *frequently* use during development against trunk (as opposed to occasional/infrequent testing)? [ ] ./configure and build entirely in-tree (httpd/srclib/* etc) [ ] ../httpd/configure into a single seperate vpath tree [x] configure for separately built or OS-provisioned expat [x] configure for separately built or OS-provisioned pcre [x] configure for separately built or OS-provisioned apr[-util] Please check off all-of-the-above that apply, thanks!
Re: svn commit: r925858 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS docs/manual/mod/core.xml server/config.c
On 2010-03-21 at 16:14, William A. Rowe Jr. wr...@rowe-clan.net wrote: No-match of a wildcard must result in an error. Why? It doesn't before this change. E.g. Include /existingdirectory/nosuchfile*.conf starts without error, and that seems fine to me - the directive says to include all files matching that pattern, and all zero files that match are indeed included. Dan
Re: svn commit: r921347 - /httpd/httpd/trunk/modules/proxy/mod_proxy_http.c
On 2010-03-10 at 08:37, s...@apache.org wrote: Author: sf Date: Wed Mar 10 13:37:00 2010 New Revision: 921347 URL: http://svn.apache.org/viewvc?rev=921347view=rev Log: log remote server port in various places Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_http.c Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_http.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_http.c?rev=921347r1=921346r2=921347view=diff What's the criteria for which messages had the port number added? Any reason not to just add it everywhere possible? Dan
Re: Undocumented core directive: Protocol
On 2010-02-26 at 13:32, Paul Querna p...@querna.org wrote: On Thu, Feb 25, 2010 at 5:20 AM, Eric Covener cove...@gmail.com wrote: On Thu, Feb 25, 2010 at 8:03 AM, Dan Poirier poir...@pobox.com wrote: 1) When you use the Protocol directive, which listening ports is it applied to? 2) Why would you choose to use the Protocol directive, instead of adding the protocol to the Listen directive? Looking at this cold, I think the answer to this is that Protocol is per-vhost. I'm not sure it should be, IIRC protocol was introduced before protocols on the Listener command, and their only practical use is deciding if we should use kernel level accept filters. I'm honestly thinking that it could be possible to kill the command, if people are happy with having to use the listen command to spec it. Because it 'inherits' the protocol form the Listen Directive, these two configurations are functionally identical: Listen 443 VirtualHost *:443 Protocol https ... /VirtualHost And: Listen 443 https VirtualHost *:443 ... /VirtualHost So, I kinda think the value isn't there anymore, and maybe we should consider just removing the directive, and tell people to use the protocol on the listen command? I agree. The only effect of the Protocol setting seems to be to control what accept filter is applied to the listening socket, so it logically goes with the listen configuration, not the virtual host. Putting different Protocol statements in different VirtualHosts can't work, since the different virtual hosts can be sharing a single listening socket, and a given socket can only have one accept filter configuration. What would the process be? Remove the directive from trunk, and label it deprecated in 2.2's documentation? Dan
Download page recommends 2.3.5-alpha over all previous releases
I just noticed this at http://httpd.apache.org/download.cgi: The Apache HTTP Server Project is pleased to announce the release of Apache HTTP Server, version 2.3.5-alpha. This release represents ten years of innovation by the project, and is recommended over all previous releases! I think this should probably match the front page, which clearly labels this as an alpha release. Dan
Re: [vote] release 2.2.15?
[Non-binding] +1 md5sums good sha1sums good pgp sig matches that in http://www.apache.org/dist/httpd/KEYS Mac OS 10.6.2 (Snow Leopard): No regressions from 2.2.14, though you still have to build with CC=cc -m32 to get a working server, and there are still test failures, but the same ones as in 2.2.14. Linux RHEL-5 x86: Built okay, all tests passed. Dan
Wildcards internal to Include paths matching files
Re: this proposal:
* core: Support wildcards in both the directory and file components of
the path specified by the Include directive.
Trunk patch: http://svn.apache.org/viewvc?rev=909878view=rev
2.2.x patch: http://people.apache.org/~minfrin/httpd-wildcard+docs.patch
With the code currently in trunk and proposed for backport, if an
interior wildcard matches something not a directory, it results in a
fatal error. E.g. if I have
Include /foo/conf/*/*.conf
and this file happens to exist
/foo/conf/httpd.conf
then you end up with this error:
httpd: Syntax error on line 472 of /path/to/serverroot/conf/httpd.conf:
Could not open config directory /foo/conf/httpd.conf: Not a directory
I think if the configuration says Include /foo/conf/*/*.conf, the user
isn't expecting files in /foo/conf to be included, and we should just
skip over them.
If people agree with that behavior, here's a proposed implementation.
Either way, the behavior should be documented. (I can add doc, unless
Graham wants to do it, once the right behavior is agreed on.)
Index: config.c
===
--- config.c(revision 916378)
+++ config.c(working copy)
@@ -1710,8 +1710,17 @@
strcmp(dirent.name, ..)
(apr_fnmatch(fname, dirent.name,
APR_FNM_PERIOD) == APR_SUCCESS)) {
+const char *full_path = ap_make_full_path(ptemp, path,
dirent.name);
+if (rest) {
+/* If matching internal to path, and we happen to match
something other than a directory, skip it */
+apr_finfo_t finfo;
+rv = apr_stat(finfo, full_path, APR_FINFO_TYPE, ptemp);
+if ((rv == APR_SUCCESS) (finfo.filetype != APR_DIR)) {
+continue;
+}
+}
fnew = (fnames *) apr_array_push(candidates);
-fnew-fname = ap_make_full_path(ptemp, path, dirent.name);
+fnew-fname = full_path;
}
}
Undocumented core directive: Protocol
On 2010-02-09 at 09:27, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=42912 Developers, Christian Ress kindly contributed documentation for the Protocol directive. I'd like to expand it a bit before committing; can anyone help me with these questions? 1) When you use the Protocol directive, which listening ports is it applied to? 2) Why would you choose to use the Protocol directive, instead of adding the protocol to the Listen directive? Thanks, Dan
State of mod_lua?
What's the state of mod_lua? I've thought about trying it out, but haven't yet, in part because there doesn't seem to be any documentation under httpd trunk. Dan
Re: What goes in CHANGES and svn log comments?
On 2010-02-06 at 10:36, Dan Poirier poir...@pobox.com wrote: * In trunk, does CHANGES document the changes from the last stable release, or from the previous alpha release of trunk? That would affect whether backported fixes should be mentioned in trunk CHANGES. Does anyone have comments on this question? Thanks, Dan
Re: svn commit: r910673 - /httpd/httpd/trunk/server/config.c
On Tue, Feb 16, 2010, at 03:30:21 PM, Jeff Trawick traw...@gmail.com wrote: == --- httpd/httpd/trunk/server/config.c (original) +++ httpd/httpd/trunk/server/config.c Tue Feb 16 20:24:33 2010 @@ -1670,7 +1670,7 @@ int current; /* find the first part of the filename */ - rest = ap_strchr(fname, '/'); + rest = ap_strchr((char*)fname, '/'); Casting isn't the right fix, which I guess is to make rest const char * and then use ap_strchr_c() instead of ap_strchr() (hopefully that doesn't snowball). Thanks, that works without snowballing.
Re: svn commit: r910684 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_log.h server/log.c server/mpm/event/event.c server/mpm/netware/mpm_netware.c server/mpm/prefork/prefork.c serv
On Tue, Feb 16, 2010, at 04:03:33 PM, Jeff Trawick traw...@gmail.com wrote: FWLIW, sooner or later somebody will want quoting around args with embedded blanks (surprisingly there doesn't seem to be an existing function to do this work) Maybe something along these lines would be useful? /** * Concatenate multiple strings specified in a writev-style vector. * The separator between strings is the sep argument, and each string * has the quote argument preceding and following it. * * @param p The pool from which to allocate * @param vec The strings to concatenate * @param nvec The number of strings to concatenate * @param nbytes (output) strlen of new string (pass in NULL to omit) * @param sep String to place between each input string (pass in NULL to omit) * @param quote String to place around each input string (pass in NULL to omit) * @return The new string */ APR_DECLARE(char *) apr_pstrjoinv(apr_pool_t *a, const struct iovec *vec, apr_size_t nvec, apr_size_t *nbytes, const char *sep, const char *quote);
What goes in CHANGES and svn log comments?
Do we have any formal conventions (i.e. written down) on what kinds of changes require entries in CHANGES and what doesn't, and what information we include in CHANGES and svn log entries? The most logical place for something like that seems to be near the bottom of http://httpd.apache.org/dev/guidelines.html, but I'm not seeing anything there. If we don't have any documentation of our conventions, I'll volunteer to write something (if there seems to be consensus on what the conventions are). Dan
Re: What goes in CHANGES and svn log comments?
Thanks Jeff. Some thoughts and questions for all: * I'd think that all security fixes should be mentioned in CHANGES, with CVE number, regardless of other considerations. Otherwise people worry. * Should minor changes in the wording of a message be mentioned in CHANGES? I'd guess not, even though somebody just might be depending on that wording. * I would think Submitted-by is required for all code provided by a non-committer, yes? * Can we take it for granted that the person doing the commit has reviewed the code being committed that someone else contributed, or should we make a point of stating that explicitly in the log? * In trunk, does CHANGES document the changes from the last stable release, or from the previous alpha release of trunk? That would affect whether backported fixes should be mentioned in trunk CHANGES. * I think many changes to STATUS can get by with minimal log messages, e.g. vote or propose backport. Dan
Re: svn commit: r906779 - /httpd/httpd/trunk/docs/manual/configuring.xml
[Moving discussion from dev@ to d...@httpd.apache.org] On Fri, Feb 5, 2010, at 06:57:58 AM, Jeff Trawick traw...@gmail.com wrote: On Thu, Feb 4, 2010 at 9:48 PM, poir...@apache.org wrote: + pOnly environment variables defined before the server is started + can be used in expansions. Variables defined in the + configuration file itself, for example with directive + module=mod_envSetEnv/directive, take effect too late to be + used for expansions in the configuration file./p I think the take effect too late... wording supports the common confusion that OS-level environment variables and those server variables that are set in the environment of sub-processes are essentially the same thing. I don't know what the magic distinguishing words are. Perhaps OS environment variable, with a link to a new glossary entry, should be used in the appropriate places? The glossary entry for Environment variable describes the difference but doesn't introduce unique terminology for the two types of variables (http://httpd.apache.org/docs/2.2/glossary.html#environmentvariable. I agree that it's still ambiguous or even misleading. I played with trying to expand on that, but couldn't come up with wording I liked last night. It would definitely help to have unique terminology. Maybe operating system environment variables for the ones set outside the server in the OS, and server environment variables for the ones set inside the server? There's still some possible confusion because the server variables become operating system environment variables for CGI scripts, though. If we can find consensus on terminology, I'll update the glossary and the env page http://httpd.apache.org/docs/trunk/env.html, and try to find and disambiguate as many references as I can find and link back to the glossary. Dan
Re: [PATCH] LogLevel refactoring part 1
On Wed, Feb 3, 2010, at 03:22:21 AM, Stefan Fritsch s...@sfritsch.de wrote: ap_log_error_wrapper.diff: On C99 compilers, avoid argument setup and function call overhead if the log message will be discarded anyway. Also allow to disable higher loglevels at compile time by defining APLOG_MAX_LOGLEVEL. On pre-C99 compilers, it should just work like before. This seems like a reasonable thing to do. I can't comment on the correctness, not being up on C99. Is there some server coding convention calling for trailing _ and __ on the macro and function names? If not, my personal preference would be something more meaningful when reading the code. I'd love to know difference this makes in processor usage under load, between running with loglevel debug and something lower. Saving a function call for every logging line on the main path could be a big win. loglevel_trace.diff: Introduce additional log levels trace1 ... trace8 above the debug level. If we're thinking about expanding control of debug messages, my inclination would be to work toward allowing independent control of messages from different parts of the code or about different things, rather than a strict series of increasing levels of logging. E.g. maybe today I'd like to see all debug trace from authentication, but tomorrow just see SSL stuff. Dan
Re: [PATCH] report reached MaxClients more than once
Nice. Maybe change count to messages_skipped but that's just a quibble. I wonder where else this would be handy? Dan
Re: svn commit: r906039 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c ssl_engine_config.c ssl_engine_init.c ssl_engine_kernel.c ssl_private.h
How about logging a dire warning during startup if insecure renegotiation has been enabled? Dan
Re: svn commit: r904768 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/core.xml server/core.c
I'm just curious, why use Define with ! rather than creating a new Undefine directive? Dan
Re: mod_reqtimeout backport
Stefan Fritsch s...@sfritsch.de writes: In any case, we need at least three values to completely define the behaviour. IIRC I chose the initial timeout/maximum timeout over the startup time/maximum timeout approach because it was easier to implement. I still think it's ok, given that for normal configurations, there is not much difference. But the headerinit keyword is just a bit too cryptic for my taste. Do you agree that using RequestReadTimeout instead of RequestTimeout and using a single keyword with a timeout range is more descriptive than the current syntax? Yes, I like that better too. Dan
Front page - ApacheCon US 2009
I noticed that http://httpd.apache.org still invites folks to attend ApacheCon US 2009, which was last November. Maybe it's time to change that to link to the video archives, and announce whatever the next ApacheCon will be. Dan
Re: mod_reqtimeout backport
Stefan Fritsch s...@sfritsch.de writes: I am not particularly happy about the syntax, yet. I just had the idea to have one keyword xxx that can optionally accept a range, instead of two keywords xxxinit and xxxmax: Header=30 Body=5-50 BodyMinRate=500 or Header=5-20,minrate=500 Body=5-50,minrate=500 but the combination Header=5,minrate=1000 is less clear. Maybe make the '-' mandatory in this case: Header=5-,minrate=1000 Any opinions or better ideas? One could also rename RequestTimeout into RequestReadTimeout if that makes it easier to understand. We might simplify the model by not exposing the internal extending of the timeout. Just let the admin specify an overall max time, a minimum rate, or both: HeaderTimeout: Maximum seconds to read the entire header. HeaderMinRate: Minimum rate (bytes/second) allowed when reading the request header. If the rate drops below this, the request is timed out. We'd enforce both if specified. In that case HeaderTimeout would act like headermax. Internally we'd probably implement HeaderMinRate by gradually extending a timeout, but we wouldn't be tied to that. Dan
Re: mod_reqtimeout backport
Plüm, Rüdiger, VF-Group ruediger.pl...@vodafone.com writes: -Original Message- From: news [mailto:n...@ger.gmane.org] On Behalf Of Dan Poirier We might simplify the model by not exposing the internal extending of the timeout. Just let the admin specify an overall max time, a minimum rate, or both: HeaderTimeout: Maximum seconds to read the entire header. HeaderMinRate: Minimum rate (bytes/second) allowed when reading the request header. If the rate drops below this, the request is timed out. We'd enforce both if specified. In that case HeaderTimeout would act like headermax. Internally we'd probably implement HeaderMinRate by gradually extending a timeout, but we wouldn't be tied to that. But that would result in different behaviour, wouldn't it? e.g. with init timeout set to 10 max timeout set to 30 and minrate set 500 the client can wait for 10 seconds before sending data at a rate of 500 bytes/sec. If I understand your model correctly we would cancel the request anytime if the client falls below 500 bytes/sec. So if it does start only with 200 bytes/sec we would cancel it immediately. Yes, my proposal probably simplifies things too much. We could allow some time for things to get going. Maybe not start enforcing the minimum rate until after some number of seconds, with a reasonable default but it could be configured: HeaderStartupTime: time in seconds before the specified HeaderMinRate starts being enforced. Default = 10 seconds. I'm not thrilled with that though, it's inelegant.
mod_reqtimeout backport (was: svn commit: r897527 - /httpd/httpd/branches/2.2.x/STATUS)
Some comments based on http://people.apache.org/~sf/mod_reqtimeout.2.2.patch: Code: - The units are confusing in the computation and use of the rate_factor values. rate_factor is computed as apr_time_from_sec(1)/min_rate where min_rate's units are bytes/second, so the units for the rate_factor are seconds^2/(10^6 * bytes). Then in extend_timeout(), that gets multipled by a length in bytes, so we end up with units of seconds^2/10^6 where we really want microseconds. I think it would be clearer to write the computation of the rate_factor as rate_factor = APR_USEC_PER_SEC / min_rate so the units work out as usec/byte and the timeout ends up in usec. (Yes, you end up with the same numbers, but it took me quite a while to prove that to myself, given that the units weren't right.) - I'd feel better if most of the AP_DEBUG_ASSERTs were replaced by code that would fail the request. In production this could result in crashes at runtime if any of these bad return values actually happen. - If headermax precedes headerinit on the RequestTimeout directive line, there's no check that headerinit = headermax. Similarly for bodymax and bodyinit. Documentation: - Should the module status still be Experimental if it's backported? - Compatibility should show this available in 2.2.something if it's backported. - s/timout/timeout/g - Maybe an explanatory paragraph should be added, about xxxinit and xxxminrate and xxxmax and how they relate to each other and affect the timeout of requests. That would resolve some questions I had as I was reading through this, like why is this called headerinit instead of headerread?. Dan
Re: svn commit: r896392 - in /httpd/httpd/branches/1.3.x: README src/CHANGES
c...@apache.org writes: --- httpd/httpd/branches/1.3.x/README (original) +++ httpd/httpd/branches/1.3.x/README Wed Jan 6 11:13:11 2010 @@ -14,8 +14,17 @@ The Latest Version -- - Details of the latest version can be found on the Apache HTTP - server project page under http://httpd.apache.org/. + As of January 2010, version 1.3 of Apache has reached its end + of life. Future security updates will be available as patches, + via; + +http://www.apache.org/dist/httpd/patches/ It might be worth emphasizing that there's no commitment to produce any future updates, even for security issues, and even if patches were provided for something, they wouldn't be official Apache code releases. Dan
Re: svn commit: r896392 - in /httpd/httpd/branches/1.3.x: README src/CHANGES
Ruediger Pluem rpl...@apache.org writes: IMHO patches in the patches directory are as official as previous patches. Oh, sorry, I didn't realize that. I don't think I've ever seen a vote to release a patch.
Re: [VOTE] Formal deprecation of 1.3.x branch
Colm MacCárthaigh c...@allcosts.net writes: Because ... stealing an idea from wrowe@ ... how about we formally deprecate the 1.3.x branch? Make one more release, but attach a notice to the effect that it will be the final release, and that in future we'll be distributing security updates by other means :-) (non-binding) +1 While we're at it, how about issuing a statement regarding how much longer 2.0.x will be supported? It doesn't seem to get much maintenance attention these days either. Dan
