ap_hook_monitor example

2007-06-13 Thread Mark W. Humphries

Hi,

I'm looking for an example of module code that uses the monitor hook. 
Any help would be greatly appreciated.


Cheers,
Mark Humphries


RE: httpd attempts to open file.html/.htaccess (is this a bug?)

2007-06-13 Thread Allen Pulsifer
Hello William,

Thanks for the suggestions.  I have a fix that is pretty simple (and
therefore I hope, unlikely to break anything ;-).  Later today, after I've
compiled and tested it on both Windows and Linux, I'll post it to the list.

Allen



patch for spurious open attempt on .../file.html/.htaccess

2007-06-13 Thread Allen Pulsifer
server/request.c lines 930 to 940 currently read:

if (r-finfo.filetype
#ifdef CASE_BLIND_FILESYSTEM
 (filename_len = canonical_len)
#endif
 ((opts.opts  (OPT_SYM_OWNER | OPT_SYM_LINKS)) ==
OPT_SYM_LINKS))
{

thisinfo.filetype = APR_DIR;
++seg;
continue;
}


Here is the corrected code that fixes the spurious open attempt on the file
.../file.html/.htaccess:

if (r-finfo.filetype
#ifdef CASE_BLIND_FILESYSTEM
 (filename_len = canonical_len)
#endif
 (opts.opts  OPT_SYM_LINKS) )
{
++seg;

if (r-finfo.filetype == APR_REG
 (!r-path_info || !*r-path_info) )
{
  thisinfo.filetype = APR_REG;
break;
}

thisinfo.filetype = APR_DIR;
continue;
}


A note on what this fix and the optimization accomplishes:

In the best case (under Linux with FollowSymLinks and AllowOverride's
enabled), this code makes the following accesses to disk:

1. An initial stat on the file to serve
2. An open attempt on the .htaccess in each directory along the path to the
file
3. An open on the file to serve

As far as I can see, the only way this could be optimized further would be
to eliminate the initial stat on the file to serve, or to turn it into a
file open, and then hold the file open until it is served.

Allen



Re: code docs corrections for FollowSymLinks and SymLinksIfOwnerMatch

2007-06-13 Thread Ruediger Pluem


On 06/13/2007 05:30 AM, Allen Pulsifer wrote:

 
 mod_rewrite.c lines 4461 to 4468 currently read:
 
 if (!(ap_allow_options(r)  (OPT_SYM_LINKS | OPT_SYM_OWNER))) {
 /* FollowSymLinks is mandatory! */
 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
  Options FollowSymLinks or SymLinksIfOwnerMatch is off
 
  which implies that RewriteRule directive is forbidden:
 
  %s, r-filename);
 return HTTP_FORBIDDEN;

Hm. This looks wrong to me. We should only allow RewriteRules in the directory
context if OPT_SYM_LINKS is set since we do not do any check on the result of a
RewriteRule with respect to symlinks. So we cannot be sure that the result of 
the
RewriteRule fulfils the conditions promised by OPT_SYM_OWNER.

Regards

RĂ¼diger



RE: code docs corrections for FollowSymLinks and SymLinksIfOwnerMatch

2007-06-13 Thread Allen Pulsifer
 Hm. This looks wrong to me. We should only allow RewriteRules 
 in the directory context if OPT_SYM_LINKS is set since we do 
 not do any check on the result of a RewriteRule with respect 
 to symlinks. So we cannot be sure that the result of the 
 RewriteRule fulfils the conditions promised by OPT_SYM_OWNER.

That could be, I don't know the answer, but httpd currently allows
RewriteEngine on if either FollowSymlinks or SymLinksIfOwnerMatch is
enabled.  Try it in an .htaccess:

Options -FollowSymlinks +SymLinksIfOwnerMatch
RewriteEngine On

Allen



Re: pid_table (Was: Re: svn commit: r543511 - /httpd/httpd/branches/1.3.x/src/main/http_main.c)

2007-06-13 Thread Jim Jagielski


On Jun 6, 2007, at 9:13 AM, Jim Jagielski wrote:



In the meantime, should I create a 2.2 branch for the 2.2-version
of the pid_table code and backport the changes to that?
Unless I hear otherwise, I'll likely do that since the
backport from 2.2 to 2.0 shouldn't be that involved.



Done and done: passes tests.

   http://svn.apache.org/repos/asf/httpd/httpd/branches/httpd-2.2- 
pid-table


Next to come is 2.0, but, IMO, we should start folding these
in, ala 1.3


Re: rewrite url with query string causing issues

2007-06-13 Thread Joachim Zobel
Hi.

Check out the QSA option for the RewriteRule. 

If this does not help the module developers list

[EMAIL PROTECTED]
is the appropriate place for such a question.

Sincerely,
Joachim





RE: patch for spurious open attempt on .../file.html/.htaccess

2007-06-13 Thread Allen Pulsifer
  if (r-finfo.filetype == APR_REG
   (!r-path_info || !*r-path_info) )

 Possible stupid question, but why do we need this path_info check?

ap_directory_walk uses r-path_info to hold the portion of the path that has
not yet been walked.  The check on r-path_info tells us if we are at the
end of the line, i.e., if there are no more path segments to append and
check.  Note that the loop is a little warped: it checks htaccess, appends
the next segment, lstat's the new appended path, then loops back to check
htaccess on the appended path, etc.  So at the time we are doing the
optimization, we are working with the path that has just had the next
segment appended and has not yet been checked for anything.

This inner if statement says if the full path points to a regular file and
if we have no more path segments to check after this one, then break the
loop.  It is in part the same test that is done at line 887--the comment
there reads Time for all good things to come to an end?.

Having explained the code, I realize that the test is not exactly what it
should be.  It does not handle the case of being at the end of the line
with an unknown file type.

To handle this case, the code should read as follows:

if (r-finfo.filetype
#ifdef CASE_BLIND_FILESYSTEM
 (filename_len = canonical_len)
#endif
 (opts.opts  OPT_SYM_LINKS) )
{
++seg;

if (r-path_info  *r-path_info)
{
thisinfo.filetype = APR_DIR;
continue;
}
else if (r-finfo.filetype == APR_REG)
{
  thisinfo.filetype = APR_REG;
break;
}
}

The inner if's now say:

1. If we have more path segments to check after this one, treat this segment
as a directory and continue with the path walk.

2. Else, we have no more path segment to check after this one, therefore:

(a) If the full path we are checking is a regular file, we are done with all
checks and can break from the loop

(b) else, treat the current path as unknown and continue on with the lstat.

It should be noted that this optimization is not completely optimal with a
filesystem that is not case sensitive like Windows.  With
CASE_BLIND_FILESYSTEM, the computation of canonical_len compares
r-canonical_filename to r-path_info, then deducts the filename
(file.html). As a result, canonical_len will always be less than the full
path length and the test (filename_len = canonical_len) will be false once
the file name itself (file.html) is appended to r-filename.  The net
result is that the final lstat will always be performed a second time on the
full path length.  This could be fixed, but since I'm not sure exactly how
all the canonical_filename stuff is used, I'm not going to touch it.

The Windows code has more problems than that though, since it actually walks
and stats each component in the path twice (see file I/O log included
below.)  It does it a first time in
ap_process_request_internal-ap_run_translate_name-ap_core_translate-apr_f
ilepath_merge (win32 version) which includes an apr_stat on each subdir in
path until it finds a file.  Then it stats each component in the path a
second time in ap_directory_walk.  The unix version of apr_filepath_merge
does not contain an apr_stat so this is not a problem.

 Could you please provide it as a unified diff against trunk?

Attached and included inline, a diff -u against v2.2.4.  It should apply
fine to the trunk since the relevant code has not changed.

--- .svn/text-base/request.c.svn-base   2007-06-04 23:40:23.801630400 -0400
+++ request.c   2007-06-13 18:25:27.104542400 -0400
@@ -931,13 +931,21 @@
 #ifdef CASE_BLIND_FILESYSTEM
  (filename_len = canonical_len)
 #endif
- ((opts.opts  (OPT_SYM_OWNER | OPT_SYM_LINKS)) ==
OPT_SYM_LINKS))
+ (opts.opts  OPT_SYM_LINKS) )
 {
+++seg;

+if (r-path_info  *r-path_info)
+{
 thisinfo.filetype = APR_DIR;
-++seg;
 continue;
 }
+else if (r-finfo.filetype == APR_REG)
+{
+thisinfo.filetype = APR_REG;
+break;
+}
+}

 /* We choose apr_stat with flag APR_FINFO_LINK here, rather
that
  * plain apr_stat, so that we capture this path object rather
than


--

Effect of patch

Configuration:

docroot: /usr/local/apache/htdocs
AllowOverrides and FollowSymLinks are enabled

request: http://localhost/dir/subdir/file.html
This file exists, and there is an .htaccess in the docroot


Linux file I/O:

[pid 10755] stat64(/usr/local/apache2/htdocs/dir/subdir/file.html,
{st_mode=S_IFREG|0644, st_size=48, ...}) = 0
[pid 10755] 

revised patch for spurious open attempt on .../file.html/.htaccess

2007-06-13 Thread Allen Pulsifer
After sending that last post, I realized that if the full path points to a
directory, it will do a final lstat even though it doesn't need to.

That's easy to fix.  Here is the revised code, the revised patch, and test
output.

CODE:

if (r-finfo.filetype
#ifdef CASE_BLIND_FILESYSTEM
 (filename_len = canonical_len)
#endif
 (opts.opts  OPT_SYM_LINKS) )
{
++seg;

if (r-finfo.filetype == APR_DIR || (r-path_info 
*r-path_info))
{
thisinfo.filetype = APR_DIR;
continue;
}
else if (r-finfo.filetype == APR_REG)
{
thisinfo.filetype = APR_REG;
break;
}
}

PATCH:

--- .svn/text-base/request.c.svn-base   2007-06-04 23:40:23.801630400 -0400
+++ request.c   2007-06-13 19:54:37.050034200 -0400
@@ -931,13 +931,21 @@
 #ifdef CASE_BLIND_FILESYSTEM
  (filename_len = canonical_len)
 #endif
- ((opts.opts  (OPT_SYM_OWNER | OPT_SYM_LINKS)) ==
OPT_SYM_LINKS))
+ (opts.opts  OPT_SYM_LINKS) )
 {
+++seg;

+if (r-finfo.filetype == APR_DIR || (r-path_info 
*r-path_info))
+{
 thisinfo.filetype = APR_DIR;
-++seg;
 continue;
 }
+else if (r-finfo.filetype == APR_REG)
+{
+thisinfo.filetype = APR_REG;
+break;
+}
+}

 /* We choose apr_stat with flag APR_FINFO_LINK here, rather
that
  * plain apr_stat, so that we capture this path object rather
than


TEST OUTPUT:

request: http://localhost/dir/subdir/ (with an index.html file)

[pid 14461] stat64(/usr/local/apache2/htdocs/dir/subdir/,
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 14461] open(/usr/local/apache2/htdocs/.htaccess,
O_RDONLY|O_LARGEFILE) = 12
[pid 14461] open(/usr/local/apache2/htdocs/dir/.htaccess,
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 14461] open(/usr/local/apache2/htdocs/dir/subdir/.htaccess,
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 14461] stat64(/usr/local/apache2/htdocs/dir/subdir/index.html,
{st_mode=S_IFREG|0755, st_size=51, ...}) = 0
[pid 14461] open(/usr/local/apache2/htdocs/dir/subdir/index.html,
O_RDONLY|O_LARGEFILE) = 12


request: http://localhost/dir/subdir/file.html

[pid 14462] stat64(/usr/local/apache2/htdocs/dir/subdir/file.html,
{st_mode=S_IFREG|0644, st_size=48, ...}) = 0
[pid 14462] open(/usr/local/apache2/htdocs/.htaccess,
O_RDONLY|O_LARGEFILE) = 12
[pid 14462] open(/usr/local/apache2/htdocs/dir/.htaccess,
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 14462] open(/usr/local/apache2/htdocs/dir/subdir/.htaccess,
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 14462] open(/usr/local/apache2/htdocs/dir/subdir/file.html,
O_RDONLY|O_LARGEFILE) = 12


request.c.diff
Description: Binary data


revised(3) patch for spurious open attempt on .../file.html/.htaccess

2007-06-13 Thread Allen Pulsifer
I hate to have to do this...

I realized that ++seg should only be incremented when the optimization
results in either a continue or a break.  Here is the correction:

CODE:

if (r-finfo.filetype
#ifdef CASE_BLIND_FILESYSTEM
 (filename_len = canonical_len)
#endif
 (opts.opts  OPT_SYM_LINKS) )
{
if ((r-path_info  *r-path_info) || r-finfo.filetype ==
APR_DIR)
{
thisinfo.filetype = APR_DIR;
++seg;
continue;
}
else if (r-finfo.filetype == APR_REG)
{
thisinfo.filetype = APR_REG;
++seg;
break;
}
}

PATCH:

--- .svn/text-base/request.c.svn-base   2007-06-04 23:40:23.801630400 -0400
+++ request.c   2007-06-13 21:34:01.659559100 -0400
@@ -931,13 +931,21 @@
 #ifdef CASE_BLIND_FILESYSTEM
  (filename_len = canonical_len)
 #endif
- ((opts.opts  (OPT_SYM_OWNER | OPT_SYM_LINKS)) ==
OPT_SYM_LINKS))
+ (opts.opts  OPT_SYM_LINKS) )
+{
+if ((r-path_info  *r-path_info) || r-finfo.filetype ==
APR_DIR)
 {
-
 thisinfo.filetype = APR_DIR;
 ++seg;
 continue;
 }
+else if (r-finfo.filetype == APR_REG)
+{
+thisinfo.filetype = APR_REG;
+++seg;
+break;
+}
+}

 /* We choose apr_stat with flag APR_FINFO_LINK here, rather
that
  * plain apr_stat, so that we capture this path object rather
than


ANALYSIS:

The optimization formerly skipped the lstat and went directly to the
htaccess check, even when it reached the point of checking the full path and
the full path referred to a file.  This resulted in a spurious open attempt
on .../file.html/.htaccess

The revised optimization also skips the lstat and goes directly to the
htaccess check, but only when (a) the directory walk has not yet reached the
full path; or (b) the full path refers to a directory.

Otherwise, when it reaches the full path, if the full path refers to a
regular file, it terminates the directory walk.  If the file type of the
full path is not a directory or a regular file, it continues on with the
unoptimized lstat of the full path.


request.c.diff
Description: Binary data


[STATUS] (httpd-2.0) Wed Jun 13 23:49:53 2007

2007-06-13 Thread Rodent of Unusual Size
APACHE 2.0 STATUS:  -*-text-*-
Last modified at [$Date: 2007-05-08 19:18:57 -0400 (Tue, 08 May 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.60  : in maintenance
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. ]

* ApacheMonitor: Fix Windows Vista detection.
  http://svn.apache.org/viewvc?view=revrevision=536052  
  +1: mturk
  
*) 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, wrowe
 wrowe adds; looks 

[STATUS] (httpd-2.2) Wed Jun 13 23:51:04 2007

2007-06-13 Thread Rodent of Unusual Size
APACHE 2.2 STATUS:  -*-text-*-
Last modified at [$Date: 2007-06-01 13:31:49 -0400 (Fri, 01 Jun 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.5   : In Development
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:

* ApacheMonitor: Fix Windows Vista detection.
  http://svn.apache.org/viewvc?view=revrevision=536052  
  +1: mturk
  wrowe notes post today to list, can we please test for = VISTA
  so this doesn't break again upon the release of longhorn server
  or 'nextgen' windows?
 
* mpm_winnt: Fix return values from wait_for_many_objects.
  Note - this is required to avoid hangups of socket #64, #128
  as Microsoft set aside 64 reserved values.
  Trunk version of patch:
http://svn.apache.org/viewvc?view=revrevision=428029
  2.2.x version of patch:
Trunk version works
http://people.apache.org/~wrowe/mpm_winnt_waits.patch
is easier to read (-U8)
  +1: mturk
  +0: fielding (patch is okay, underlying code is crap)
  wrowe notes: a patch should have the necessary effect with the
minimum lines of code - there's alot of redecorating that's
going on in this patch to no net effect.  The WAIT_TIMEOUT
result value seems to be ignored in the revised code?
  mturk notes: WAIT_TIMEOUT is replaced by WAIT_FAILED with
the accompanied patch in mpm\winnt\child.c.
  fielding notes: the routine is brain-dead -- one cannot replicate
a wait for many objects by iterating through multiple waits with
a one second sleep in between loops.  That's insane.
The right ways to do that are explained in the MSDN article
http://msdn2.microsoft.com/en-us/library/ms687025.aspx
In any case, it should be checking nCount = MAXIMUM_WAIT_OBJECTS
first and use the simple wait in that case.

   * 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
 +1: minfrin
 niq: This wants a little tidying.  Use of 13 as a magic number (for a
  strlen of 

[STATUS] (httpd-trunk) Wed Jun 13 23:55:48 2007

2007-06-13 Thread Rodent of Unusual Size
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: rewrite url with query string causing issues

2007-06-13 Thread sonia mukherjee

Hi,
Thanx for the reply, i am already using the QSA flag. On further
investgation i have found out that this query string is getting lost during
a particular API call to Apache namely
ap_parse_uri(request_rec *  r,  const char *  uri). I have also found out on
Apache docs that this API call has the side effect of losing the particular
query parameter ( r-args).Now could any body suggest a similar API call
that doesnot have an affect like this.

Thanx in advance

Sonia


On 6/14/07, Joachim Zobel [EMAIL PROTECTED] wrote:


Hi.

Check out the QSA option for the RewriteRule.

If this does not help the module developers list

[EMAIL PROTECTED]
is the appropriate place for such a question.

Sincerely,
Joachim