activated. It may be bumpy for a few days, and we have more optimizations
to put in place, but it's time to get this in the developer's test code.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91359 13f79535-47bb-0310-9956-ffa450edef68
I ended up blasting these (intentional) changes as well :(
This finishes up the changes for the new, replacement ap_directory_walk
for testing. This code isn't active yet.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91342 13f79535-47bb-0310-9956-ffa450edef68
doesn't activate that code, I will do so probably by Monday, after more
thorough testing.
Introduces the ap_directory_walk::cache so we can stop wasting tons of
effort in mod_autoindex and other subreq/redirect requests.
This isn't thoroughly tested, I've only stepped through a half dozen
common cases. If you want to play, define REPLACE_PATH_INFO_METHOD.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91340 13f79535-47bb-0310-9956-ffa450edef68
as the parent request. Also pulls a bunch of notes and code that was
set aside, we don't need this with the other optimizations introduced.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91254 13f79535-47bb-0310-9956-ffa450edef68
after deleting the EOS bucket.
This prevents a seg fault in mod_include when the connection dies. There
doesn't seem to be much point in passing empty brigades in general.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91225 13f79535-47bb-0310-9956-ffa450edef68
If we are *already* a faux URI (i.e. relative file sub req) and we then
make a subrequest from that faux URI to a file in the same directory,
we'd try to build a URI out of the fake URI which leads to the wrong
thing happening somewhere down the line. So, let's just give this
special case a fake URI as well.
OtherBill needs to verify this. He can back it out if he wants. I
don't much care. It's one line and it seems okay...
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91187 13f79535-47bb-0310-9956-ffa450edef68
Eliminate URI-centric phases in ap_process_request_internal() for pure
file subrequests (that don't correspond to URI space.) translate_name
hook and location_walks are skipped for these requests.
Moves the reset of the per_dir_config out of directory_walk into the
internal request processing code, so that resources with alternate
map_to_storage requirements start with clean r->server->lookup_defaults.
Optimizes out the authn/authz of effectively identical subreqests and
redirects, as the sub_req_lookup calls once did. Unlike 1.3, we copy
r->user and r->ap_auth_type from main/prev for the request's reference.
Stop copying the subrequest's r->chunked flag (Rbb assured me it looked
bogus, chunking is on the parent request) and clean out other #if 0'ed
cruft we don't need to refer back to anymore.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91169 13f79535-47bb-0310-9956-ffa450edef68
ending to this filename-less request a bit later in the request cycle, to
give older, ported modules more time to cope without implementing
the map_to_storage hook.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91131 13f79535-47bb-0310-9956-ffa450edef68
caller -- ap_process_request_internal() -- catches that and returns
OK to its caller -- ap_process_request(). But ap_process_request(),
seeing OK, tries to run a handler. It needs to skip that if the
request was completed in ap_process_request_internal().
Reviewed by: William A. Rowe, Jr.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91095 13f79535-47bb-0310-9956-ffa450edef68
on attempting a subreq/redirect or simply a second pass, and for each
match in series, if the section is a match, we reuse the merge result
for that section.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90925 13f79535-47bb-0310-9956-ffa450edef68
after any other map_to_storage operations.) Therefore, initialize any
NULL r->per_dir_config at this phase (the earliest necessary point.)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90868 13f79535-47bb-0310-9956-ffa450edef68
We hadn't prepared for this possibility that someone didn't set up the
r->per_dir_config (which the subreq's didn't). Since we are first in
line, we will handle it if need be.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90865 13f79535-47bb-0310-9956-ffa450edef68
----------------------------------------------------
if the base paths are the same
if (strncmp(rnew->filename, fdir, fdirlen) == 0
and there's more stuff in the new filename than just the base path
&& rnew->filename[fdirlen]
and that stuff contains no slashes
&& ap_strchr_c(rnew->filename + fdirlen, '/') == NULL)
----------------------------------------------------
Assuming that's a correct translation, which I believe to be the case
(and which also seems to jive with the previous version of the test),
then that first part darned well better check == 0, as opposed to != 0.
strncmp returns 0 when they match. =-)
And voila,
"All tests successful, 1 test skipped."
is the result from httpd-test
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90842 13f79535-47bb-0310-9956-ffa450edef68
from the primary request, redirects and sub-requests.
This will significantly reduce opporunities for inconsistancy (such
as Ian observed, and as I repaired only a month ago.)
This promotes process_request_internal to an ap_ namespace protected
entity in server/request.c (from it's old home in http/http_request.c)
since this fn has no http specifics.
Reviewed (in concept): Cliff Woolley, Ian Holsman
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90833 13f79535-47bb-0310-9956-ffa450edef68
We will note the end result of the merge, and if remains the same through
the second pass, we have nothing whatsoever to do :)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90714 13f79535-47bb-0310-9956-ffa450edef68
amount of redundant effort (it must be run twice, but it will no
longer reparse all <Location > blocks when the request uri
hadn't changed.)
The location walk block is refactored, with some significant changes
in variable names for legibility. Cooler still, it uses pool data
instead of 'notes' for the important cache info :)
Note the patch builds the <Location > per dir config from _nothing_,
and then merges it into the per_dir_config. When the underlying
per_dir_config changes between passes, the location_walk can simply
tack back on this preconstruct onto the new per_dir_config.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90713 13f79535-47bb-0310-9956-ffa450edef68
ap_directory_walk() phase. Modules that want to use special
walk logic should refer to the mod_proxy map_to_location example,
with it's proxy_walk and proxysection implementation. This makes
either directory_walk flavor much more legible, since that phase
only runs against real <Directory > blocks.
On a technical note, this patch also forces the Directory to be
canonical (unless it is "/" or a regex.) It also allows us to
be more explicit when declaring <Directory > block errors.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90684 13f79535-47bb-0310-9956-ffa450edef68
the directory_walk and file_walk for non-file requests. TRACE
shortcut moved to http_protocol.c as APR_HOOK_MIDDLE, and the
directory_walk/file_walk happen as APR_HOOK_VERY_LAST in core.c.
A seperate patch to mod_proxy is required to short circuit both the
TRACE and directory_walk/file_walk stuff. That patch is next.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90665 13f79535-47bb-0310-9956-ffa450edef68
out the last patch before I rearranged this to be _readable_.
Next step for everyone's sanity, provide <Proxy > directives ;)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90646 13f79535-47bb-0310-9956-ffa450edef68
This patch does one thing, it changes the root path "/" to reflect an
element count of Zero (0). directory_walk will always accept the zero
element (which sorts first, thankfully) on it's first go around.
So, Unix will accept "/" when it's parsing it's first element "/".
Dos/Win32 will accept "/" and "C:/" when they parse their first element,
"C:/". The root sorted first, so it behaves as users expect.
The syntax "//" or "//machine" will be depreciated for now, the user
needs to set up the extact "//machine/share/" that they want served
on Win32.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90644 13f79535-47bb-0310-9956-ffa450edef68
Therefore we will canonicalize it when it doesn't match filename.
The next optimization should take the path common to canonical_filename
and filename, and start merging filename from there for canonicalization.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90591 13f79535-47bb-0310-9956-ffa450edef68
consuming on all but *nix systems) we temporarily canonicalize to compare
the results of the many merges, and fail on a mismatch.
The apr_filepath_merge and ap_server_root_relative calls now merge the
file _by canonicalizing it_. That includes resolving all /../, /./,
and // misnomers.
A minor effort is required to figure out who all munges the r->filename
in an inappropriate manner.
The final (return to optimized state) probably involves setting an
r->goodname argument to r->filename, every time we properly merge
through ap_server_root_relative or apr_filepath_merge().
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90573 13f79535-47bb-0310-9956-ffa450edef68
by calling ap_allow_options() before setting rnew->per_dir_config.
This is the "easy looking" fix but might have side effects of which I'm
unaware... please double-check this change for correctness.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89978 13f79535-47bb-0310-9956-ffa450edef68
we are in a file subrequest (think of a file server-status sitting in
the document root, this shouldn't be blindly served as a 'file'.)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89934 13f79535-47bb-0310-9956-ffa450edef68
a genuine bug...
The old logic
if (!(opts & OPT_SYM_OWNER | OPT_SYM_LINKS))
wouldn't seem to work properly. I think it would act like
if (!((opts & OPT_SYM_OWNER) | OPT_SYM_LINKS))
This clearly isn't intended since OPT_SYM_LINKS is a constant non-zero, such
that we never really fail invalid parameters.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89860 13f79535-47bb-0310-9956-ffa450edef68
the new resolve_symlink (also used by the new directory_walk)
especially for performance and readability. Left check_symlinks
in the soon-to-be-gone get_path_info flavor of directory_walk.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89856 13f79535-47bb-0310-9956-ffa450edef68
check_symlinks, in a protected define REPLACE_PATH_INFO_METHOD.
This allows others to work on vetting, caching, etc, while keeping
the existing logic stable till it's sufficiently optimal for beta.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89847 13f79535-47bb-0310-9956-ffa450edef68
