be used when the key was not found in the dbm.
apr_dbm_fetch() returns APR_SUCCESS as long as there was no I/O
error. mod_rewrite needed to look further to see if the key
was actually found.
PR 13204
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@97106 13f79535-47bb-0310-9956-ffa450edef68
maps.
For now, the SDBM dbm flavor is always used. It won't be compatible
with dbm rewrite maps built for Apache 1.3 until apr-util supports
ndbm and mod_rewrite is changed to prefer ndbm over the built-in
sdbm.
PR: 10644
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96478 13f79535-47bb-0310-9956-ffa450edef68
the inappropriate use of nonblocking reads. Also get rid of the stderr
altogether since mod_rewrite never uses it.
PR: 9534
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96475 13f79535-47bb-0310-9956-ffa450edef68
configuration is like the following
RewriteRule (.*) - [CO=<cookiename>:$1:<domain>:<expiry in minutes>]
Submitted by: Brian Degenhardt <bmd@mp3.com>
Reviewed by: Ian Holsman
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95840 13f79535-47bb-0310-9956-ffa450edef68
last little changes. ->datafile should be initialized... but doing so
brings up the fact that the check in run_rewritemap_programs() was
expecting ->datafile to have a string attached to it. For clarity,
let's just use argv[0] there. And since we've reinstated the use of
->checkfile, we no longer need that extra apr_stat() I hacked in,
so let's get rid of it.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95375 13f79535-47bb-0310-9956-ffa450edef68
just use that information later. I was having a problem with prg
directives with arguments failing the configuration. The problem was
a call to stat, which was being passed the program name and the arguments.
Obviously, the arguments were messing up the call to stat. This gets the
test suite working for me again.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95372 13f79535-47bb-0310-9956-ffa450edef68
can't just apr_stat in the first init round because we haven't run
apr_tokenize_to_argv() yet, and it would be a relatively ugly hack to run
it twice just for that. Well, I suppose we could store the argv in the
rewritemap structure, but ... nah. With this, we shutdown (cleanly, as
opposed to the old exit(1) method) if we go to execute a rewritemap
and discover it doesn't exist, and log a nice descriptive message at the
end of the error_log.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95337 13f79535-47bb-0310-9956-ffa450edef68
on mod_rewrite. This, along with the original usage of a unix-only
function in mod_rewrite, is a temporary stopgap measure designed only
to workaround limitations in APR's handling of permission attributes.
It shall be removed as soon as that interface is improved.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94972 13f79535-47bb-0310-9956-ffa450edef68
silently failing when locking/unlocking the mutex, since httpd
child processes didn't have permissions to access the root-created
semaphore.
PR: 8143
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94969 13f79535-47bb-0310-9956-ffa450edef68
1. rename ap_rset_content_type to ap_set_content_type
2. reverse the arguments on the call to aligh with ap_set_content_length
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94056 13f79535-47bb-0310-9956-ffa450edef68
of Jeff Trawick's style changes to the first patches. Doesn't include
the fixes to ssl [more complex], and we won't trap errors that involve
ap_serverroot, since we presume that was normalized on the way in.
Therefore, testing ap_server_root_relative(DEFAULT_FOO) cases
should never become necessary.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93965 13f79535-47bb-0310-9956-ffa450edef68
parent process, don't we?
This -was- post-fork() in 1.3, but with the massive restructuring,
we inadvertantly now whack the parent process.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93587 13f79535-47bb-0310-9956-ffa450edef68
causing the server not to start.
previous method was to call exit(1) which would not fail
gracefully
PR:
Obtained from:
Submitted by:
Reviewed by: (Idea only Jeff Trawick)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92144 13f79535-47bb-0310-9956-ffa450edef68
