httpd-2.0/2.2 API dictionary by Doxygen
Hi all, I searched for quite some time but can't locate it. Is it not available online and require to compile by ourself? I can only find the old 1.3 API in http://httpd.apache.org/dev/apidoc/ and the APR API in http://apr.apache.org/docs/apr/. Regards, -Fai
Re: debug apache
On Die 20.06.2006 14:15, Jeff Trawick wrote: [snipped] A past discussion of very closely related functionality, though not exactly what you asked for originally, yielded multiple interested admin-type folks and no developers expressing interest other than myself. Sorry, i think i have misunderstood your last mail. Regards Alex
Re: debug apache
On Die 20.06.2006 18:40, William A. Rowe, Jr. wrote: Jeff Trawick wrote: A past discussion of very closely related functionality, though not exactly what you asked for originally, yielded multiple interested admin-type folks and no developers expressing interest other than myself. And also Jeff's already suggested you bring the subject up at [EMAIL PROTECTED] Since Apache httpd is not the only program using apr, you might find -more- developers interested in working on this feature since it would help their program as well. Hm well, i will overthink this, i'am not very glad for this, but i sounds the logical correct way. regards Alex
Re: svn commit: r415945 - /httpd/httpd/trunk/build/rpm/httpd.spec.in
[EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewvc?rev=415945view=rev Log: Add zlib-devel to the BuildReq in the RPM Spec file, which allows mod_deflate to be built. Is it possible to backport this to v2.2? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r415945 - /httpd/httpd/trunk/build/rpm/httpd.spec.in
Graham Leggett wrote: [EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewvc?rev=415945view=rev Log: Add zlib-devel to the BuildReq in the RPM Spec file, which allows mod_deflate to be built. Is it possible to backport this to v2.2? I'm not going to stop you :) -Paul
Re: svn commit: r415945 - /httpd/httpd/trunk/build/rpm/httpd.spec.in
On Wed, June 21, 2006 11:24 am, Paul Querna wrote: Is it possible to backport this to v2.2? I'm not going to stop you :) Don't have proper net access right now :) (Stupid firewalls) Regards, Graham --
Re: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODO
like alteon load balancer from nortel... they provide health check for many protocole...for http is only simple get to backend... and on the backend you must provide a responde this check (ex:statics file)...you can define how many ping after how it consider the backend dead...and how many seconds between ping...From: Jim Jagielski [mailto:[EMAIL PROTECTED]To: dev@httpd.apache.orgSent: Mon, 19 Jun 2006 23:02:11 +0200Subject: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODORuediger Pluem wrote: +1. Just one thought: I think it would be useful to have this 'health check' approach somewhat generic so that we can implement the call to it inside mod_proxy and its connection pooling itself (e.g. with providers supplied by schema handlers / modules). For AJP this would be CPING/CPONG of course and mod_proxy itself could offer a generic TCP connection 'health check' provider that simply checks the status of a TCP connection as far as this is possible without reading or writing data. This would be a very generic provider. Other protocol handlers could define other (better) protocol specific providers and just plug them in. Agreed. Making a generic hearbeat interface that could vary dependingon the actual protocol would be v. cool. So for AJP, CPING/CPONG,for HTTP some sort of generic TRACE (or HEAD)...-- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODO
why not add proxy hook like scheme handler do to that ?From: Ruediger Pluem [mailto:[EMAIL PROTECTED]To: dev@httpd.apache.orgSent: Mon, 19 Jun 2006 23:04:55 +0200Subject: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODOOn 06/19/2006 10:23 PM, Mladen Turk wrote: Henri Gomez wrote: Good to see that PING/PONG got such a good response here. When I added this to mod_jk it was just a quick way to detect hang JVMs but it seems to many on the TC-DEV not a very usefull feature :) And may thanks for such a great idea Henri ;) Actually its a great way to detect all those busy/broken/hanged/disconnected servers. I'm not sure how we could add that feature to the http/https protocol, the Rudiger suggested.To be honest I currently have no generic idea how to do this withoutsupport from the backend. My point was more about that I would loveto see this health check integrated into the generic code of mod_proxyand its connection pooling and let the protocol modules provide the codethat actually does the dirty work of the protocol specific aspects of such ahealth check. This would make it easy to add health checks for other protocols/ add better ones for protocols with existing ones. As said currently I wouldonly see two health check providers:- CPING/CPONG for AJP.- A generic TCP connection check.But this would be open to further bright ideas.RegardsRüdiger
Re: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODO
you must have the possibility to add a wheight to each backend to moderate the load (like nortel alteon)... no?From: Mladen Turk [mailto:[EMAIL PROTECTED]To: dev@httpd.apache.orgSent: Tue, 20 Jun 2006 09:02:44 +0200Subject: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODOHenri Gomez wrote: Important point in load balancing will be to collect CPU load (job load) from the remote. We often make the mistake to split requests between servers as if it cost the same CPU power (or cpu load) for each of them, but in Java / J2EE some requests could be more CPU/IO/DB consuming than others.Well, I'm not sure that having the CPU load would mean something.For example you might have P3/1GHz and P66/100GHz with thesame load (close to 80%), and that info in that case would beactually misleading. It might help only if your hardware topologyis exactly the same for all backend servers.The bussines method OTOH will favor the 100GHz box over 1GHz one,thus giving more sense. Even with the same hardware topology,it is presumable that the shorter reply timeout would mean lessCPU cycles used.Regards,Mladen.
Re: [EMAIL PROTECTED] Re: debug apache
i'm not sure that only apr solution because is httpd information to log... no hook only information...but can be acheve with hook of hook... and this idea can be posted to [EMAIL PROTECTED]but can be apache hook impl super macro to acheve this...and the information to log rely on apache log mecanic...and must be activable/desactivable like extended status...Regards,MAthieuFrom: Alexander Lazic [mailto:[EMAIL PROTECTED]To: dev@httpd.apache.orgSent: Wed, 21 Jun 2006 09:42:59 +0200Subject: [EMAIL PROTECTED] Re: debug apacheOn Die 20.06.2006 18:40, William A. Rowe, Jr. wrote:Jeff Trawick wrote:A past discussion of very closely related functionality, though notexactly what you asked for originally, yielded multiple interestedadmin-type folks and no developers expressing interest other thanmyself.And also Jeff's already suggested you bring the subject up at [EMAIL PROTECTED].Since Apache httpd is not the only program using apr, you might find-more- developers interested in working on this feature since it wouldhelp their program as well.Hm well, i will overthink this, i'am not very glad for this, but isounds the logical correct way.regardsAlex
Re: [PATCH] setenvif filter
Anyone else care to vote on this so it can get, possibly, committed? Francois Pesce wrote: These patches may fix the r-content_type behaviour. Are you OK with it ? -- *Francois Pesce* 2006/5/31, Brian Akins [EMAIL PROTECTED]: Francois PESCE wrote: I've discussed about a patch for mod_setenvif 2 years ago, and have coded it at that time, it is successfully used on various host in production since. You need to handle content type specially by checking r-content_type. For some reason, just doing apr_table_get(r-headers_out, Content-type) would be null, but content_type would be set. See the patch I posted a few days ago. +1 in concept -- Brian Akins Lead Systems Engineer CNN Internet Technologies -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: hook call tracing [was: debug apache]
Alexander Lazic wrote: On Sam 17.06.2006 00:54, Ruediger Pluem wrote: On 06/16/2006 10:28 PM, Alexander Lazic wrote: Any opinion from the developer, to this issue?! On Don 01.06.2006 08:14, Alexander Lazic wrote: Is it possible to get a logentry from the hooks in apache to see the flow of a request? eg: $REQUEST accepted on $FD [snipp] From my current point of view the answer is: No, this is not possible out of the box. It may be possible if you modify the hook macros. And do you think that the developer would accept a patch for apache 2.x and would apply it? Just to be clear; there is no patch (yet) to review? n quick observations; * I've built this myself, it was non trivial so never submitted for consideration, and I didn't like my own hack anyways. * There's some context missing from the hook structure that would be necessary to do this. Most importantly, the name of the target for the hook's call. This could be the source file or the name of the module it resides in or both. * I was never really happy with just 'we called X'. It wasn't worth presenting to the list until there's some method to decode the args, potentially args in - args out. -OR-... * Rather than args, what about a hook formatter function that could display whatever -relevant- fields (e.g. uri + filename during the translation parsing hook, user and pseudo-passwd during auth) that usually apply to the intended purpose of the hook. * To save hassles, there should be an empty formatter by default until various hooks learn to format. * We want to record that the module accepted, declined or returned an explicit status from it's hook call. This is definately useful for module developers, and should be added. It seems our hackathon in Dublin is the best place to kick around ideas? Actually, Nick and I will probably kick this around Saturday or Sunday since he's presenting to that crowd (module authors) on Monday. (And to the original poster, your recent comments are demotivating; you are generally guarenteed not to have your problem solved by guilting devs into writing a patch for you, and even if this patch happens, don't expect a similar reaction to your future posts. Write it, pay someone to do it for you, or keep your tone polite but insistent that it benefits the entire community. Remember the developers scratch their own itch, not yours, owe you, personally, nothing.) Bill
Re: hook call tracing [was: debug apache]
William A. Rowe, Jr. wrote: This is definately useful for module developers, and should be added. +1. it is also useful, when you have strange things happening to production web servers. I, too, did a rather ugly hack that shouwed the current hook using mod_status hook and it has come in handy. It is however very ugly. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: svn commit: r416165 - /httpd/httpd/trunk/modules/filters/mod_deflate.c
On 06/22/2006 01:16 AM, wrote:
Author: niq
Date: Wed Jun 21 16:16:47 2006
New Revision: 416165
URL: http://svn.apache.org/viewvc?rev=416165view=rev
Log:
PR#39854
Remove bogus code that chokes on flush buckets
if (APR_BUCKET_IS_FLUSH(bkt)) {
-apr_bucket *tmp_heap;
-zRC = inflate((ctx-stream), Z_SYNC_FLUSH);
-if (zRC != Z_OK) {
-ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
- Inflate error %d on flush, zRC);
-inflateEnd(ctx-stream);
-return APR_EGENERAL;
-}
-
-ctx-stream.next_out = ctx-buffer;
-len = c-bufferSize - ctx-stream.avail_out;
-
-ctx-crc = crc32(ctx-crc, (const Bytef *)ctx-buffer, len);
-tmp_heap = apr_bucket_heap_create((char *)ctx-buffer, len,
- NULL, f-c-bucket_alloc);
-APR_BRIGADE_INSERT_TAIL(ctx-proc_bb, tmp_heap);
-ctx-stream.avail_out = c-bufferSize;
-
-/* Move everything to the returning brigade. */
-APR_BUCKET_REMOVE(bkt);
-break;
+continue;
Is this correct? In fact you ignore flush buckets now. Shouldn't you add the
flush bucket to
ctx-proc_bb, pass it up the chain, clean ctx-proc_bb afterwards and break if
the result is not
ok?
Regards
Rüdiger
Re: svn commit: r416165 - /httpd/httpd/trunk/modules/filters/mod_deflate.c
On Thursday 22 June 2006 00:38, Ruediger Pluem wrote: Is this correct? In fact you ignore flush buckets now. Yes, this ignores flush buckets - which is better than choking on them. I'm not aware of this being a problem worth worrying about unduly, but feel free to correct me. Shouldn't you add the flush bucket to ctx-proc_bb, pass it up the chain, clean ctx-proc_bb afterwards and break if the result is not ok? In principle, yes. Except for the break. But needs delving deeper into libz than I feel able to do right now, to figure out if there's going to be an issue of orphaned data. I believe the real life flush bucket causing the error report is coming before the compressed data. -- Nick Kew
[STATUS] (httpd-2.0) Wed Jun 21 23:48:32 2006
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2006-05-01 08:57:25 -0400 (Mon, 01 May 2006) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS Documentation status is maintained seperately and can be found at: * docs/STATUS in this source tree, or * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS Consult the following STATUS files for information on related projects: * http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x/STATUS * http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x/STATUS Consult the trunk/ for all new development and documentation efforts: * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS Release history: 2.0.59 : In development 2.0.58 : released May 1, 2006 as GA. 2.0.57 : Tagged on April 19, 2006. Not released. 2.0.56 : Tagged on April 16, 2006. Not released. 2.0.55 : released October 16, 2005 as GA. 2.0.54 : released April 17, 2005 as GA. 2.0.53 : released February 7, 2005 as GA. 2.0.52 : released September 28, 2004 as GA. 2.0.51 : released September 15, 2004 as GA. 2.0.50 : released June 30, 2004 as GA. 2.0.49 : released March 19, 2004 as GA. 2.0.48 : released October 29, 2003 as GA. 2.0.47 : released July 09, 2003 as GA. 2.0.46 : released May 28, 2003 as GA. 2.0.45 : released April 1, 2003 as GA. 2.0.44 : released January 20, 2003 as GA. 2.0.43 : released October 3, 2002 as GA. 2.0.42 : released September 24, 2002 as GA. 2.0.41 : rolled September 16, 2002. not released. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the bug database at: http://issues.apache.org/bugzilla/ * Review the PatchAvailable bugs in the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable After testing, you can append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: * Forward binary compatibility is expected of Apache 2.0.x releases, such that no MMN major number changes will occur. Such changes can only be made in the trunk. * All commits to branches/2.0.x must be reflected in SVN trunk, as well, if they apply. Logical progression is commit to trunk, get feedback and votes on list or in STATUS, then merge into branches/2.2.x, and finally merge into branches/2.0.x, as applicable. RELEASE SHOWSTOPPERS: PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] PATCHES PROPOSED TO BACKPORT FROM TRUNK: [ please place SVN revisions from trunk here, so it is easy to identify exactly what the proposed changes are! Add all new proposals to the end of this list. ] *) Reverse Proxy fixes: Location bug and Cookie support Patch is at http://people.apache.org/~colm/httpd-2.0-reverse-proxy-cookie.patch and is in production with Clients. +1: niq +1: wrowe; looks good, no way to apply this without a minor bump *) Backport 102870; PR 17217; stop linking OpenSSL to support/* binaries (especially when compiled --with-static-support (!))
[STATUS] (httpd-2.1) Wed Jun 21 23:50:36 2006
APACHE 2.3 STATUS: -*-text-*-
Last modified at [$Date: 2006-05-31 15:34:37 -0400 (Wed, 31 May 2006) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS
Documentation status is maintained seperately and can be found at:
* docs/STATUS in this source tree, or
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS
Consult the following STATUS files for information on related projects:
* http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
* http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS
Patches considered for backport are noted in their branches' STATUS:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
Release history:
[NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
while x.{even}.z versions are Stable/GA releases.]
2.3.0 : in development
Contributors looking for a mission:
* Just do an egrep on TODO or XXX in the source.
* Review the bug database at: http://issues.apache.org/bugzilla/
* Review the PatchAvailable bugs in the bug database:
https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2keywords=PatchAvailable
After testing, you can append a comment saying Reviewed and tested.
* Open bugs in the bug database.
CURRENT RELEASE NOTES:
RELEASE SHOWSTOPPERS:
* Handling of non-trailing / config by non-default handler is broken
http://marc.theaimsgroup.com/?l=apache-httpd-devm=105451701628081w=2
jerenkrantz asks: Why should this block a release?
wsanchez agrees: this may be a change in behavior, but isn't
clearly wrong, and even if so, it doesn't seem like a
showstopper.
* the edge connection filter cannot be removed
http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2
jerenkrantz asks: Why should this block a release?
stas replies: because it requires a rewrite of the filters stack
implementation (you have suggested that) and once 2.2 is
released you can't do that anymore.
CURRENT VOTES:
* If the parent process dies, should the remaining child processes
gracefully self-terminate. Or maybe we should make it a runtime
option, or have a concept of 2 parent processes (one being a
hot spare).
See: Message-ID: [EMAIL PROTECTED]
Self-destruct: Ken, Martin, Lars
Not self-destruct: BrianP, Ian, Cliff, BillS
Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd
/* The below was a concept on *how* to handle the problem */
Have 2 parents: +1: jim
-1: Justin, wrowe, rederpj, nd
+0: Lars, Martin (while standing by, could it do
something useful?)
* Make the worker MPM the default MPM for threaded Unix boxes.
+1: Justin, Ian, Cliff, BillS, striker, wrowe, nd
+0: BrianP, Aaron (mutex contention is looking better with the
latest code, let's continue tuning and testing), rederpj, jim
-0: Lars
pquerna: Do we want to change this for 2.2?
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
* Patches submitted to the bug database:
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable
* Filter stacks and subrequests, redirects and fast redirects.
There's at least one PR that suffers from the current unclean behaviour
(which lets the server send garbage): PR 17629
nd says: Every subrequest should get its own filter stack with the
subreq_core filter as bottom-most. That filter does two things:
- swallow EOS buckets
- redirect the data stream to the upper request's (rr-main)
filter chain directly after the subrequest's starting
point.
Once we have a clean solution, we can try to optimize
it, so that the server won't be slow down too much.
* RFC 2616 violations.
Closed PRs: 15857.
Open PRs: 15852, 15859, 15861, 15864, 15865, 15866, 15868, 15869,
15870, 16120, 16125, 16126, 16133, 16135, 16136, 16137,
16138, 16139, 16140, 16142, 16518, 16520, 16521,
jerenkrantz says: need to decide how many we need to backport and/or
if these rise to showstopper status.
wrowe suggests: it would be nice to see MUST v.s. SHOULD v.s. MAY
out of this list, without reviewing them individually.
* There is a bug in how we sort some hooks, at
