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 th
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 se
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 main
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 main
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
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
> > 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
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
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 don
> 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
On 06/13/2007 02:09 PM, Allen Pulsifer wrote:
Thanks for the patch. Could you please provide it as a unified diff against
trunk?
Believe it or not but I guess that is easier to read for many (most?) people
here
than (this is old code / this is new code) :-).
> server/request.c lines 930 to 94
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,
> "O
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.fi
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
14 matches
Mail list logo
