Re: RFE: Control of HTTP cache control headers within mod_rewrite rules
I ran some tests on this and the following modified version will work:
Header always set Cache-Control max-age=%{CACHE_LIFETIME}e
env=CACHE_LIFETIME
RewriteRule /example http://www.example.com/ [E=CACHE_LIFETIME:604800]
..however, this still leaves an open question in my mind: How to solve for
the more general case where I want Apache to set the cache control header on
any 301 it sends, even if the 301 was generated within the application
rather than in Apache's configuration. I don't see a way to set an
environment variable based on a response attribute (e.g. r->status). Am I
missing something or would something need to be written to handle this case?
Noah
On Sun, Oct 23, 2011 at 5:02 PM, Rowan Collins wrote:
>
> I haven't got a test environment to hand right now, but that looks
> promising - I didn't spot the conditional form of Header directive; clearly
> I should have read the page more carefully. ;)
>
> I'm not sure if directive order would matter, but in principle maybe
> something like this would work:
>
> Header set Cache-Control max-age=%{CACHE_LIFETIME}e env=CACHE_LIFETIME
> RewriteRule /example http://example.com [R=302,E=CACHE_LIFETIME:**604800]
>
> I'll have to play around, and let you know how I get on - thanks for the
> tip.
> Regards,
> Rowan
>
>
>
Re: Problems with mod_mbox
On Thu, Jul 23, 2009 at 08:48:23AM -0700, Paul Querna wrote: > mod_mbox is open source: > > <http://svn.apache.org/repos/asf/httpd/mod_mbox/trunk/> > > patches welcome :) I'm kept more than busy enough with CouchDB! Heh. > The Infra team isn't aware of a good alternative, but sure, if there > was one, we would consider using it. Well, the W3C use hypermail: http://www.hypermail-project.org/ And it weems to work well enough for them: http://lists.w3.org/Archives/Public/semantic-web/2009Jul/0137 Is there a list I should address this suggestion to? > I wouldn't call it 'dead', but sure, mostly unmaintained. It needs > some loving, especially on the user interface. Does the ASF have any way of promoting jobs like this? There may be someone with a chunk of spare time to improve this software. And we already missed this year's Google Summer of Code. Best, -- Noah Slater, http://tumbolia.org/nslater
Problems with mod_mbox
Hey, I just sent the following email to the CouchDB developer list: http://mail-archives.apache.org/mod_mbox/couchdb-dev/200907.mbox/<20090722214200.ga11...@tumbolia.org> Preparing these emails is such a chore, I thought I'd post some comments here: * The URIs are really horrible. Is there any way of shortening them? Perhaps a shorter MID based URI would help, like: http://mail-archives.apache.org/mid/20090722214200.ga11...@tumbolia.org That would make things much more managable via email. * With the following list: http://mail-archives.apache.org/mod_mbox/couchdb-dev/200907.mbox/browser If you click to open in a new tab, you get this: http://mail-archives.apache.org/mod_mbox/couchdb-dev/200907.mbox/ajax/<921000906301118y3bb11937hf6c0cd433387e...@mail.gmail.com> Which is just awful, really. * As I am forced to not use this feature of my UA, if I just click a link in the normal way, I am taken to some two-pane display. I would provide a link here, but I can't because of the way "Ajax" has been used. A bigger concern is that if I press my browsers back button, I am taken back to front page of the list, which is totally broken. I know there's a "click here to get a permalink" hack, but that's not very useful as I'm trying to browse around and my back button has been broken. Sorry if I seem like a total arse, I'm just feeling a frustrated! Heh. Is this project being actively maintained? The last news item was from 2005. If the project is dead, maybe the ASF should consider ditching it's use for our mailing lists. It's a royal pain in the arse at the moment. Thanks, -- Noah Slater, http://tumbolia.org/nslater
Re: Do these broken clients still exist?
On Sun, Apr 03, 2005 at 01:58:56PM -0400, Joshua Slive wrote: > Does someone with a high-traffic, general-interest web site want to take a > look through their logs for these user-agent strings. I don't mind > keeping them if they make up even 1/100 of a percent of the trafic, but it > seems silly to keep these extra regexes on every single request if these > clients don't exist anymore in the wild. [snip] > BrowserMatch "Mozilla/2" nokeepalive I still see this; .001% of ~2M requests from the following full UA strings: Mozilla/2.0 (compatible; Ask Jeeves/Teoma; +http://sp.ask.com/docs/about/tech_crawling.html)" Mozilla/2.0 (compatible; MS FrontPage 4.0)" Mozilla/2.0 (compatible; MS FrontPage 5.0)" Mozilla/2.0 (compatible; MSIE 3.02; Update a; AK; Windows 95)" Mozilla/2.0 (compatible; MSIE 3.02; Windows 95)" Mozilla/2.0 (compatible; MSIE 3.02; Windows CE)" Mozilla/2.0 (compatible; MSIE 3.02; Windows CE; PPC; 240x320) BlackBerry7100/4.0.0 Profile/MIDP-2.0 Configuration/CLDC-1.1" Mozilla/2.0 (compatible; MSIE 3.02; Windows CE; PPC; 240x320)" Mozilla/2.0 (compatible; MSIE 3.0; Windows 95)" Mozilla/2.0 (compatible; MSIE 3.0b; AOL 4.0; Windows 3.1)" --n -- dd of=/dev/fd0 if=/dev/flippy bs=1024 ^^^ Making Flippy Floppy
Re: Apache on AS/400 (OS400)
Hi Henri, On Fri, Feb 18, 2005 at 05:47:00PM +0100, Henri Gomez wrote: > Apache2 on iSeries is built from AIX via cross compiler :) > > I asked many time to Rochester Labs for autoconf/automake port to > iSeries but no success ,( Consider posting data about the outstanding Autoconf issues to [EMAIL PROTECTED] I suspect someone will fix them.
Re: FW: [PATCH] fix child reclaim timing
I took a look at the worker and prefork mpms and it seems that make_child registers the just_die function for SIGTERM for child processes. Now just_die does try to do a gracefull shutdown by calling clean_child_exit, but what happens if clean_child_exit gets called twice? Hopefully I'm just reading the code wrong and don't fully understand the MPM's yet. As for the timing you've described below, if SIGTERM is really safe to send multiple times to a child process, I like it much better as well. -Noah -Original Message- From: Jeff Trawick [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 6:26 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] fix child reclaim timing On Fri, 13 Aug 2004 16:48:42 -0400, Arliss, Noah <[EMAIL PROTECTED]> wrote: > I'd like to comment further... Not only is a disturbing message sent to > the > error log, but a SIGTERM is also sent to the child process. If I > understand > correctly the SIGTERM will likely interrupt any properly implemented child > process shutdown and the child process will exit ungracefully. for worker MPM, at least: child processes have a SIGTERM handler that simply sets a flag and returns to whatever was happening before; it will be the main thread of a child that receives a message via another mechanism which tells it to wake up and decide to exit the SIGTERM isn't expected to interrupt any important processing going on in the child (be it worker threads or child exit hook) SIGTERM is sent multiple times to work around any signal loss or other glitch (not sure when this is effective in reality); I don't see how it is harmful to any code that must run the SIGKILL is what yanks the rug out from under the child and any child exit hooks; the web server simply must exit in a reasonable timeframe if the administrator tells it too, stuck code or not > If it's > acceptable to wait longer then the kill call should also be postponed to > give modules a chance to cleanup gracefully. If any module has complex IPC > or Mutexes in use, graceful shutdown is important especially if > MaxRequestsPerChild is in use on a server with heavy load. > yes, the SIGKILL is the measure of last resort; shouldn't be sent for a while after we start shutting down > here is a current example: (I don't actually know when shutdown started; I should add a debug msg there; but it is very short time before this uninteresting mess starts) [Mon Jun 14 09:15:11 2004] [warn] child process 3906 still did not exit, sending a SIGTERM [Mon Jun 14 09:15:12 2004] [warn] child process 3907 still did not exit, sending a SIGTERM [Mon Jun 14 09:15:12 2004] [warn] child process 3924 still did not exit, sending a SIGTERM [Mon Jun 14 09:15:12 2004] [warn] child process 3925 still did not exit, sending a SIGTERM [Mon Jun 14 09:15:12 2004] [warn] child process 3926 still did not exit, sending a SIGTERM [Mon Jun 14 09:15:12 2004] [warn] child process 3906 still did not exit, sending a SIGTERM [Mon Jun 14 09:15:12 2004] [warn] child process 3907 still did not exit, sending a SIGTERM [Mon Jun 14 09:15:12 2004] [warn] child process 3924 still did not exit, sending a SIGTERM [Mon Jun 14 09:15:12 2004] [warn] child process 3925 still did not exit, sending a SIGTERM [Mon Jun 14 09:15:12 2004] [warn] child process 3926 still did not exit, sending a SIGTERM [Mon Jun 14 09:15:13 2004] [warn] child process 3906 still did not exit, sending a SIGTERM [Mon Jun 14 09:15:13 2004] [warn] child process 3907 still did not exit, sending a SIGTERM [Mon Jun 14 09:15:13 2004] [warn] child process 3924 still did not exit, sending a SIGTERM [Mon Jun 14 09:15:13 2004] [warn] child process 3925 still did not exit, sending a SIGTERM [Mon Jun 14 09:15:13 2004] [warn] child process 3926 still did not exit, sending a SIGTERM [Mon Jun 14 09:15:14 2004] [error] [client 127.0.0.1] request failed: error reading the headers [Mon Jun 14 09:15:15 2004] [info] (9)Bad file number: core_output_filter: writing data to the network [Mon Jun 14 09:15:17 2004] [error] child process 3906 still did not exit, sending a SIGKILL [Mon Jun 14 09:15:34 2004] [info] removed PID file /export/home/trawick/inst/20/logs/httpd.pid (pid=3903) [Mon Jun 14 09:15:34 2004] [notice] caught SIGTERM, shutting down if SIGTERM simply sets a flag and returns, what is use of repeating the SIGTERM over and over? for worker MPM it doesn't help or hurt AFAICT; worker does something else to wake up its children prior to calling the code Joe has a patch for this sounds a bit more sane to me for timing, as long as we can exit as soon as all children have exited: shutdown + 0: send SIGTERM shutdown + 4: for each child still remaining, bitch to error log and send SIGTERM again shutdown + 8: for each child still remaining, bitch to error log and send SIGTERM again shutdown + 12: for each child still remaining, bitch to error
RE: [PATCH] fix child reclaim timing
I'd like to comment further... Not only is a disturbing message sent to the error log, but a SIGTERM is also sent to the child process. If I understand correctly the SIGTERM will likely interrupt any properly implemented child process shutdown and the child process will exit ungracefully. If it's acceptable to wait longer then the kill call should also be postponed to give modules a chance to cleanup gracefully. If any module has complex IPC or Mutexes in use, graceful shutdown is important especially if MaxRequestsPerChild is in use on a server with heavy load. -Noah -Original Message- From: Jeff Trawick [mailto:[EMAIL PROTECTED] Sent: Friday, August 13, 2004 10:27 AM To: [EMAIL PROTECTED] Subject: Re: [PATCH] fix child reclaim timing On Fri, 13 Aug 2004 14:51:23 +0100, Joe Orton <[EMAIL PROTECTED]> wrote: > The 2.0 ap_reclaim_child_processes logic seems to be broken - it never > resets the waittime variable as it did in 1.3; so the parent will wait > for up to 23 minutes (sic) in total for a stuck child process. (SIGSTOP > a child and strace the parent to see for yourself) > > This updates the logic to be a little more sane: > > - at t + 16, 82, 344 ms, just waitpid() > - at t + 425, 688, 1736 ms, waitpid() else SIGTERM the child > - at t + 1.74 secs, waitpid() else SIGKILL the child > - at t + 1.75, 1.82 secs, just waitpid() > - at t + 2.08 secs, waitpid() else log "this child won't die" > > Any comments? Here is my take on what is wrong with current code: 1) It starts complaining a bit too soon. Some third-party modules have rather complicated child exit strategies. Whether or not that is good or bad (bad ;) ), it results in disturbing messages that wouldn't have appeared if we were a little more patient (2-3 seconds). Also, I suspect that the use of threaded MPM affects how quickly the children are exiting now on Unix. 2) It should never stop checking for exited processes less often than 1-2 seconds, even if it doesn't complain to error log that often. Like you say, current code can wait a VERY long time for child processes to exit. In practice, I see that it can wait a VERY long time even after the last child has exited. I'll agree that it should never wait so long, though I think around 15 or so seconds total is reasonable. Exiting before children are gone doesn't let Apache start up any more quickly; it just prevents potentially-useful information about timing from getting logged to the error log. --/-- I wouldn't complain to error log at all until it has been 2 seconds, and then I'd still wait around for 10-15 more. But it has to check every second so it finds out soon after all children have exited and doesn't sleep needlessly.
RFC: Act as Authenticated User
Hello, I wish to make users' Unix home directories available to them via WebDAV. Since the Apache HTTP Server supports WebDAV, SSL, and a variety of authentication schemes, it seemed an appropriate basis, but it does not appear to fit the bill because it always runs under a particular user account. It needs to access the exact set of files the user can access, and when it writes files it must write them as the authenticated user; it would therefore need to either run as the authenticated user or simulate that fact. Other people have noted and/or addressed this issue. MoulDAVia is a server designed for this purpose. Others[1] have achieved this functionality with apache when an AFS server shares the files to publish, as httpd can retrieve krb5 tokens for multiple AFS users. A message[2] on the dav-dev mailing list summarizes the issues for regular Unix filesystems. The best way I have thought to achieve this functionality in Apache is to add an option, say "SetuidIfAuthenticated." With that directive set, Apache will retain access to root privileges until it has authenticated the user. It will then getpwnam(3) the authenticated user name and switch to the resulting UID. If the authenticated user does not correspond to a Unix user, Apache will report an error and fall back on the account given in the User directive. I have not studied the Apache code at all, so I can't say offhand whether this approach will require changes to the Apache core or whether a module alone could implement the functionality. Is that is a good approach to the need I described? If it requires changes to the Apache core, might they be acceptable for inclusion in the standard codebase? Might any associated module become part of the standard set? Thanks. [1] http://www.cpan.org/modules/by-module/Apache/Apache-AuthKrb5Afs-1.0.readme [2] http://mailman.lyra.org/pipermail/dav-dev/1999-March/000170.html
RE: [PATCH] HPUX static's and Mixing C with C++ modules
I understand BIND_NOSTART has been in the code since it was first checked into apache 1.3. I also understand the desire not to break existing functionality. I can tell you that BIND_NOSTART prevents any C++ module developer from being able to take advantage of static initialization. I'd be more than happy to leave that code be if I had a definative way to enable dlopen instead of shl_load. -N -Original Message- From: Joe Orton [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 08, 2003 5:01 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH] HPUX static's and Mixing C with C++ modules Hi, On Fri, Feb 07, 2003 at 12:23:09PM -0500, Arliss, Noah wrote: > I'll try to clarify things as best I can. First off, BIND_VERBOSE would be > fantastic. I had to add it in order to get my module to load at all with > shl_load, even though it still would not function. If there was a good > reason to remove BIND_VERBOSE that history would be nice to have. The > shl_load call would look better as: BIND_VERBOSE means the library writes error message to whatever file you happen to have open as fd 2 - which is unacceptable for a library. (the app may have closed stderr and be using fd 2 for something completely different). You get exactly the same error string back via apr_dso_error() anyway, which is the defined interface for retrieving the error string. Changing the call to: > + shl_t os_handle = shl_load(path, BIND_IMMEDIATE, 0L); seems fine to me, FWIW, but as Will says, the BIND_NOSTART has been there since the code was first checked into Apache 1.3, so there may be some subtle reason why it's needed. Regards, joe
RE: [PATCH] HPUX static's and Mixing C with C++ modules
I'll try to clarify things as best I can. First off, BIND_VERBOSE would be fantastic. I had to add it in order to get my module to load at all with shl_load, even though it still would not function. If there was a good reason to remove BIND_VERBOSE that history would be nice to have. The shl_load call would look better as: + shl_t os_handle = shl_load(path, BIND_IMMEDIATE|BIND_VERBOSE, 0L); or + shl_t os_handle = shl_load(path, BIND_IMMEDIATE, 0L); at a minimum. The contradiction with item 3 and 4 below stem from a strange stacktrace I found for my apache 2.0 module. In apache 1.3 to get our module to run we wrote a mod_so.c shim that did not have BIND_NOSTART in the shl_load line. We use mod_so to load our shim, and then use the shim to load our module, so for apache 1.3 removing BIND_NOSTART fixed the problem. In apache 2.0 I have not yet had time to further trouble shoot the issue completely. A couple weeks ago I was testing with the latest apache 2.0 source and ran into trouble (with shl_load). I found a stack trace I saved away that appeared to be in the static initialization phase of one of our third party dependancies. I know I removed BIND_NOSTART from the apache 2.0 source, but I haven't had time to further track it. I haven't completely lost hope of getting my module to run under shl_load (since our 1.3 module does), but it is a cost of time issue, especially with the more robust dlopen available (on the HP platforms we support) and our major apache 2.0 dev effort already completed. As for the _main() issue, it should be up to the module author the more that I think about it. According to the HP docs I included in my original post, _main() should be called from the main() function of the C application, but our 1.3 module calls it in the initializer phase and has been running without problems. Is there a chance we could patch the apache 1.3 shl_load call for BIND_NOSTART as well? If so I can get rid of my shim which would be fantastic! To sum it all up: The patch looks good, module developers should handle _main, and dlopen would be really really nice to have. Thanks again, Noah -Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 30, 2003 11:32 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Arliss, Noah; [EMAIL PROTECTED] Subject: [PATCH] HPUX static's and Mixing C with C++ modules Of course I'm really happy to *finally* get some feedback on that issue (since we have few HPUX participants here, my pleas for comments went mostly unanswered.) The small bit below deserves *instant* reaction; since it can be done with very little extra logic. It seems other issues with HPUX shl_load() were identified earlier by Alexis and Joe (Joe follows this list so I didn't explicitly cc him above) ... for the resolution of BIND_VERBOSE read; http://www.contactor.se/~dast/svn/archive-2002-12/0474.shtml I'm hoping they can provide extra feedback on this patch. [And, by the way, I'm concerned that patch lost some useful diagnostics info - perhaps we should reenable BIND_VERBOSE for --maintainer-mode?] Anyways... An example thread of someone struggling here; http://h21007.www2.hp.com/cxx-dev/CXX/cxx-dev.0203/0071.html So... I'd ask you all to check out this patch (which seems very reasonable) and let me know if you encounter any issues. And Arliss... please give us some citations or reconciliation between the two comments below (they seem contradictary); At 09:43 AM 1/30/2003, Arliss, Noah wrote: >3) shl_load does not like static initialization (even with BIND_NOSTART >removed from the shl_load call). > >It would be great if one or more of the following changes could be made >(mostly from Bill's attached mail): > >4) Remove BIND_NOSTART from the bits set when calling shl_load since >that explicitly stops any static > initialization. It would be great if I could get this one into >both apache 1.3 and 2.0. Note that this code has existed since rev 1.7 of apache-1.3/src/os/unix/os.c and has never been touched since it was introduced... Revision <http://cvs.apache.org/viewcvs.cgi/*checkout*/apache-1.3/src/os/unix/os.c?re v=1.7>1.7 / <http://cvs.apache.org/viewcvs/apache-1.3/src/os/unix/os.c?rev=1.7&content-t ype=text/vnd.viewcvs-markup>(view) - <http://cvs.apache.org/viewcvs/apache-1.3/src/os/unix/os.c?annotate=1.7>anno tate - <http://cvs.apache.org/viewcvs/apache-1.3/src/os/unix/os.c?r1=1.7>[select for diffs] , Sun Apr 12 15:49:28 1998 UTC (4 years, 9 months ago) by rse Branch: <http://cvs.apache.org/viewcvs/apache-1.3/src/os/unix/os.c?only_with_tag=MAI N>MAIN Changes since 1.6: +43 -0 lines Diff to <http://cvs.apache.org/viewcvs/apache-1.3/src/os/unix/os.c.diff?r1=1.6&r2=1. 7>previous 1.6 (<http://cvs.apache.org/viewcvs/apache-1.3/src/os/unix/os.c.diff?r1=1.6&r2=1 .7&diff_format=h&
RE: reading post data
Ryan, You did respond and I do appreciate you taking the time. I have some responses to yours below. Just trying to understand, -N >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: Monday, August 19, 2002 1:24 PM >To: '[EMAIL PROTECTED]' >Subject: Re: reading post data > > > >Noah, > >I already answered your question through Jim Harter at Covalent. You >cannot pass information from an input filter to the access checker, >because the input filter runs during the handler phase, and the >access_checker function runs long before that. It wasn't clear until recently that the input filters run during the handler phase (which is after the hooks). Could we clarify the order of events here so third party developers can see the flow? I believe the answer is no, but is it possible to subvert an input filter from being executed? Is there anything I should be aware of when running as an input filter that's different from running in the hooks? >I don't think it is clear where filters fall in the order of request processing. After doing some hacking and >talking to some > >You will need to do your access checking as a part of the input filter, >and deny access within the access checker. As I told you, the HTTP_IN >filter has a couple of examples of how to do this. How could I possible do my access checking as a part of the input filter and deny access within the access checker if the access checker runs first? There are cases where I might want to deny access based on what I find in the input filter (did I say access enough here?). >While it is true that there isn't much information available for writing >input filters, the best source currently available is the filters used in >Apache itself. > >Ryan What about things like setting headers or performing a redirect from within an input filter? Are there examples of this as well. What input filters are good to look at besides ap_http_filter? On Mon, 19 Aug 2002, Arliss, Noah wrote: > Greetings, > > I have been working on a port to Apache 2.0 for some time now and have run > into a road block that I would like to get feedback on. I need to run my > module in the access_checker hook with the ability to read in Post data in a > non-destructive manor. In apache 1.3 this was possible by hacking the > request structure and putting the post data back for ap_get_client_block to > read again. In Apache 2.0 this does not appear possible and I've been told > to look at input filters. So I was wondering if it would be possible to > somehow read data in my input filter and then pass it along to the > access_checker phase? When are input filters executed? I'm hoping this will > spark a discussion on the new apache 2.0 architecture here, since there is > not a lot of information out there about filters yet and I'm sure others > will benifit from this discussion. > > Thanks in advance for the help, > > Noah Arliss > -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
reading post data
Greetings, I have been working on a port to Apache 2.0 for some time now and have run into a road block that I would like to get feedback on. I need to run my module in the access_checker hook with the ability to read in Post data in a non-destructive manor. In apache 1.3 this was possible by hacking the request structure and putting the post data back for ap_get_client_block to read again. In Apache 2.0 this does not appear possible and I've been told to look at input filters. So I was wondering if it would be possible to somehow read data in my input filter and then pass it along to the access_checker phase? When are input filters executed? I'm hoping this will spark a discussion on the new apache 2.0 architecture here, since there is not a lot of information out there about filters yet and I'm sure others will benifit from this discussion. Thanks in advance for the help, Noah Arliss
RE: CAN-2002-0392 : what about older versions of Apache?
Hopefully this is not a redundant question.. Does this patch cover issues in mod_proxy as well, or were the issues introduced in 1.3.23 and later? -N -Original Message- From: Bill Stoddard [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 9:44 AM To: [EMAIL PROTECTED] Subject: Re: CAN-2002-0392 : what about older versions of Apache? > > Some wrote... > > ... > > I must say I'm mystified by this discussion. It seems to be an > odd argument between this good practice vs that good practice. > > Roy's patch is simple, safe, and reduces the exposure substantially to a > known threat. I can't see any reason to defer letting it out; > particularly now that people have been given a few days to give voice to > any technical concerns about it. The worst outcome is that we are > embaressed - we can handle that. > > Certainly it's a good thing to be careful. Giving the right folks > a chance to look over a patch for stuff like this is a good thing. > Careful is good. It's a lot easier to be careful before the exploit > becomes widely known. > > Leaving the users with no option but to stay exposed, write their own > patch, or upgrade is pretty stern medicine for us to be proscribing. It > is very hard for some sites to upgrade. > > Let's put the patch back. +1 Bill
Apache 2.0 developer documentation
Greetings, I've started playing with apache 2.0 with respect to writing modules and I was wondering if there was an ETA for more relavent up to date documentation for developers. Many of the documents including the API document have disclaimers saying "Warning: This document has not been updated to take into account changes made in the 2.0 version of the Apache HTTP Server. Some of the information may still be relevant, but please use it with care." Noah Arliss
