Re: [PATCH 43415] Logging remote port.
Plüm wrote: 1. Please provide a patch against trunk. mod_config_logger.c hasn't changed in trunk, so the patch will work fine. 2. Please also add a patch for the documentation. Done. 3. I am not too happy with using %R, but to be honest I have no better proposal :-). Maybe other have. Well, then... ;) 4. Instead of using + return apr_psprintf(r-pool, %u, r-connection-remote_addr-port); I would prefer + return pfmt(r-pool, (int) (r-connection-remote_addr-port)); like used for log_status. Well, in log_server_port, apr_psprintf is used, so that's what I used. But I really don't care one way or the other. Is there a particular reason for using one or the other? 5. Thanks for your patch :-). Welcome :) /Adam
Re: [PATCH 43415] Logging remote port.
Nick Kew wrote: Looks more like legislation for ISPs than folks with a webserver. ISPs and hosting companies alike. I'd be sceptical about that applying to non-sessions such as HTTP requests. I think that semantics are lost on these people. Part 4: [Requirements don't apply if they're not technically possible to meet] So if Apache doesn't support this, you're exempt, yesno? :-) No, that's the beauty of it. If it is not technically possible to log stuff, then you just have to log every 500 packets instead. Go figure /Adam
Re: [PATCH 43415] Logging remote port.
-Ursprüngliche Nachricht- Von: Adam Hasselbalch Hansen Gesendet: Mittwoch, 19. September 2007 11:13 An: dev@httpd.apache.org Betreff: Re: [PATCH 43415] Logging remote port. Plüm wrote: 1. Please provide a patch against trunk. mod_config_logger.c hasn't changed in trunk, so the patch will work fine. Sorry. Just a default comment if someone sends in a patch that is not against trunk :-). 2. Please also add a patch for the documentation. Done. Fine, I have already seen it in the report. 3. I am not too happy with using %R, but to be honest I have no better proposal :-). Maybe other have. Well, then... ;) I will leave around for just one or two days. If nobody has a better idea we just take %R. Feel free to bug me if your patch falls off my radar. 4. Instead of using + return apr_psprintf(r-pool, %u, r-connection-remote_addr-port); I would prefer + return pfmt(r-pool, (int) (r-connection-remote_addr-port)); like used for log_status. Well, in log_server_port, apr_psprintf is used, so that's what I used. But I really don't care one way or the other. Is there a particular reason for using one or the other? I think that using pfmt is more efficient and burns less cycles than apr_psprintf (I think this would be also the case for log_server_port), but I may be wrong on this. Additionally pfmt checks if port is = 0 and logs a - in this case, but this should not be the case for r-connection-remote_addr-port, so we could use format_integer or apr_itoa directly. Regards Rüdiger
Re: new webaccel appliance
On 09/18/2007 07:40 PM, Roy T.Fielding wrote: On Sep 18, 2007, at 6:46 PM, Plüm, Rüdiger, VF-Group wrote: This works as designed. Please see the difference between the accept headers sent by IE6 and Firefox IE6: Accept-Encoding: gzip, deflate Firefox: Accept-Encoding: gzip,deflate IE6 adds an additional space between gzip and deflate. As the response varies on Accept-Encoding two representations of the response get saved (which are actually the same). It could be argued that this should not matter. Argued? The space does not change the value of the field (which is a comma-separated list). The question is really up to us as to how But this is only true for this special case of Accept-Encoding (and all other headers where the field-value is a comma separated list), correct? It wouldn't be true for a header whose field-content is made of *TEXT, right? How do we know if a field-value is just *TEXT or field-content LWS field-content? e.g. IMHO the field-value of the header Example below could be seen as *TEXT as well as token *separator token: Example: token1, token2 If we think it is *TEXT I think token1, token2 and token1,token2 are different values, whereas if we see it as token *separator token I think they represent the same value. much effort we make to compare the values for equality, since the non-match just makes our cache slow and bulky. Given the number Agreed. Depending on the answers above we may need to have a list of headers (like Accept-Encoding) where we compare the tokens in the field-value. For all other headers we would stay with the plain compare we do today. See also the TODO comments in mod_disk_cache.c::regen_key. Regards Rüdiger
Re: new webaccel appliance
On tis, 2007-09-18 at 22:41 +0200, Ruediger Pluem wrote: Agreed. Depending on the answers above we may need to have a list of headers (like Accept-Encoding) where we compare the tokens in the field-value. For all other headers we would stay with the plain compare we do today. See also the TODO comments in mod_disk_cache.c::regen_key. Or you implement If-None-Match and forget about this. Except that Apache mod_deflate is still broken and returns the wrong ETag (same as the unencoded entity).. see bug #39727.. The separator is only one of many things which makes the Vary:ing headers slightly different. You also have quality parameters, locales, etc etc. Regards Henrik signature.asc Description: This is a digitally signed message part
[STATUS] (httpd-2.0) Wed Sep 19 23:46:35 2007
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2007-09-14 12:31:33 -0400 (Fri, 14 Sep 2007) $] 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.62 : In maintenance 2.0.61 : Released September 7, 2007. 2.0.60 : Tagged August 10, 2007, not released. 2.0.59 : released July 28, 2006 as GA. 2.0.58 : released May 1, 2006 as GA. 2.0.57 : tagged April 19, 2006, not released. 2.0.56 : tagged 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. ] *) Backport 102870; PR 17217; stop linking OpenSSL .so's to support/* binaries (especially when compiled --with-static-support (!)) and fix mod_ssl.so to compile against .a openssl archives. http://svn.apache.org/viewcvs.cgi?rev=102870view=rev +1: wrowe, colm
[STATUS] (httpd-2.2) Wed Sep 19 23:47:25 2007
APACHE 2.2 STATUS: -*-text-*-
Last modified at [$Date: 2007-09-19 12:41:35 -0400 (Wed, 19 Sep 2007) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.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/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.2.7 : In development
2.2.6 : Released September 7, 2007.
2.2.5 : Tagged August 10, 2007, not released.
2.2.4 : Released on January 9, 2007 as GA.
2.2.3 : Released on July 28, 2006 as GA.
2.2.2 : Released on May 1, 2006 as GA.
2.2.1 : Tagged on April 1, 2006, not released.
2.2.0 : Released on December 1, 2005 as GA.
2.1.10 : Tagged on November 19, 2005, not released.
2.1.9 : Released on November 5, 2005 as beta.
2.1.8 : Released on October 1, 2005 as beta.
2.1.7 : Released on September 12, 2005 as beta.
2.1.6 : Released on June 27, 2005 as alpha.
2.1.5 : Tagged on June 17, 2005.
2.1.4 : not released.
2.1.3 : Released on February 22, 2005 as alpha.
2.1.2 : Released on December 8, 2004 as alpha.
2.1.1 : Released on November 19, 2004 as alpha.
2.1.0 : not released.
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:
* Forward binary compatibility is expected of Apache 2.2.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.2.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, as applicable.
RELEASE SHOWSTOPPERS:
PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
PATCHES PROPOSED TO BACKPORT FROM TRUNK:
[ New proposals should be added at the end of the list ]
* mpm_winnt: Eliminate wait_for_many_objects. Allows the clean
shutdown of the server when the MaxClients is higher then 257,
in a more responsive manner.
Trunk version of patch:
http://svn.apache.org/viewvc?view=revrevision=573103
http://svn.apache.org/viewvc?view=revrevision=573105
2.2.x version of patch:
http://people.apache.org/~wrowe/mpm_winnt_shutdown-2.2.patch
* mod_authn_dbd: Export any additional columns queried in the SQL select
into the environment with the name AUTHENTICATE_COLUMN. This brings
mod_authn_dbd behaviour in line with mod_authnz_ldap.
Trunk: http://svn.apache.org/viewvc?view=revrevision=466865
http://svn.apache.org/viewvc?view=revrevision=571798
http://svn.apache.org/viewvc?view=revrevision=571804
+1: minfrin
rpluem says: r466865 has a conflict in modules/aaa/mod_auth.h
r571804 has a conflict in docs/manual/mod/mod_authnz_ldap.xml
Without r571838 the documentation for mod_authn_dbd fails
to build.
* multiple files, Trivial cleanups
PR: 39518 - Christophe JAILLET
http://svn.apache.org/viewvc?view=revrevision=557837
http://svn.apache.org/viewvc?view=revrevision=557972
+1: rpluem
niq: this isn't a straight backport (which is why I dropped it).
+1 for core, modules/dav, modules/filters, and modules/ssl
Not Applicable to modules/aaa
* mod_include: Add an if directive syntax to test whether an URL
is accessible, and if so, conditionally display content. This
allows a webmaster to hide a link to a private page when the user
has no access to that page.
http://svn.apache.org/viewvc?view=revrevision=571872
http://svn.apache.org/viewvc?view=revrevision=571927
[STATUS] (httpd-trunk) Wed Sep 19 23:49:55 2007
APACHE 2.3 STATUS: -*-text-*-
Last modified at [$Date: 2006-08-22 16:41:03 -0400 (Tue, 22 Aug 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-2keywords=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
Re: Thoughts on Camillia in openssl binaries?
Tom Donovan wrote: William A. Rowe, Jr. wrote: But if mod_deflate doesn't use it, and openssl is built zlib-dynamic, they simply pitched compression from ssl sessions as well with no other adverse effects. Yes, exactly. openssl doesn't select gzip compression if zlib-dynamic and zlib1.dll is missing. The other aspect, if a zlib1.dll replacement is needed for some critical decryption flaw in zlib again, it will be nice not to force users to entirely replace openssl or mod_deflate. So I expect we'll leave it as-is. I think mod_deflate on Windows links statically (zlib.lib) while openssl is linked dynamically (zdll.lib). At 40-60kb it's no big deal either way - but the security flaw in zlib argument would seem to apply to both equally. Both static or both dynamic would be more consistent. You were right, we weren't linking to zdll.lib for mod_deflate, I'll be fixing that shortly, and working up the two patches to share, one for the APR_NO_FILE tweak, one for the stderr quirk with modperl. Had to push out these binaries first, and also now am struggling very deep inside MSVCR80/OpenSSL/ActiveState Perl on x64 and a host of bugs that some of the perl packages have, assuming they can pack pointers into int's and back out again. Sorry that mess left me distracted from the issues you raised for most of this week. Bill
