ROADMAP revision 998d56ea74f8cc733b423da076dadb0fd0a789f3
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweAPACHE 2.x ROADMAP
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe==================
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweLast modified at [$Date: 2002/10/17 17:16:04 $]
a601d863bd772fefc4dc82a883589d8be6a44811wrowe
a601d863bd772fefc4dc82a883589d8be6a44811wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweINTRODUCTION
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe------------
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweThe Apache HTTP Server project must balance two competing and disjoint
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweobjectives; maintain stable code for third party authors, distributors and
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowemost importantly users so that bug and security fixes can be quickly adopted
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowewithout significant hardship due to API changes; and continue the development
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweprocess that requires ongoing redesign to work around earlier oversights in
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowethe implementation of a fluid and flexible API.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweThe Apache HTTP Server versions, through 2.0, used the Module Magic Number
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweto reflect the relatively frequent API changes. This had the shortcoming
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweof often leaving binary download users hunting to replace their loaded third
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweparty modules. This left the third party module authors searching through
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowethe API change histories to determine the new declarations, APIs and side
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweeffects of making the necessary code changes.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweWith the simultaneous release of Apache 2.1-stable and Apache 2.2-development,
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowethe Apache HTTP Server project is moving to a more predictable stable code
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowebranch, while opening the development to forward progress without concern
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowefor breaking the stable branch. This document explains the rationale between
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowethe two versions and their behavior, going forward.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweSTABLE RELEASES, 2.{odd}.{revision}
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe------------------------------------
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweAll even numbered releases will be considered stable revisions. That means;
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe * Forward Compatibility; users are not required to find new downloads of
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe currently loaded modules to upgrade from other revisions of the same
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe version. To upgrade from 2.1.0 and 2.1.27 will require no new modules.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe However, the third party modules may break from buggy code, or code that
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe used an undocumented side effect of an API call, which may be changed to
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe close bugs or security vulnerabilities. Modules should be retested.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe Moreover, new APIs may be introduced within the lifespan of the release,
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe and it is up to the third party module author to call out what version
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe forward this module is compatible with (e.g. "Compatible with Apache
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe HTTP Server version 2.1.12 and foward.") The next stable release that
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe causes module incompatibility for 2.1.x users will be an upgrade to
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe either the current 2.2.x-development releases or the 2.3.0-stable release.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe * No Deprecated modules; although new modules may be introduced within the
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe stable release, no loadable modules or their directives will be removed
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe within the lifetime of a given stable release version. The next release
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe that deprecates old modules for 2.1.x users will be an upgrade to either
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe the 2.2.x-development release or the 2.3.0-stable release.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe * Warnings should be provided in the documentation to give users a heads up
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe that a given module or directive will disappear in the future release,
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe and advise developers that a given API will change. However, it is always
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe best to check the corresponding development release to determine the full
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe impact of such changes.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe * No 'Experimental' modules; while it may be possible (based on API changes
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe required to support a given module) to load a 2.2-development module into
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe a 2.1-stable build of Apache, there are no guarantees. Experimental
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe modules will be introduced to the 2.2-development versions and either
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe added to 2.1-stable once they are proven and compatible, or deferred
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe to the 2.3-stable release if they cannot be incorporated in the current
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe stable release due to API change requirements.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe * The stable CVS tree must not remain unstable at any time. Atomic commits
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe must be used to introduce code from the development version to the stable
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe tree. At any given time a security release may be in preparation,
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe unbeknownst to other contributors. At any given time, testers may be
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe checking out CVS head to confirm that a bug has been corrected. And as
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe all code was well-tested in development prior to committing to the stable
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe tree, there is really no reason for this tree to be broken for more than
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe a few minutes during a lengthy commit.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweDEVELOPMENT RELEASES, 2.{even}.{revision}
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe-----------------------------------------
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweAll even numbered releases designate the 'next' possible stable release,
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowetherefore the current development version will always be one greater than
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowethe stable release. Work proceeds on development releases, permitting
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowethe modification of the MMN at any time in order to correct deficiencies
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweor shortcomings in the API. This means that third party modules from one
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowerevision to another may not be binary compatible, and may not successfully
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowecompile without modification to accomodate the API changes.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweThe only 'supported' development release at any time will be the most
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowerecently released version. Developers will not be answering bug reports
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweof older development releases once a new release is available, it becomes
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowethe resposibility of the reporter to use the latest development version
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweto confirm that the bug still exists.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweAny new code, new API features or new ('experimental') modules may be
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowepromoted at any time to the next stable release, by a vote of the project
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowecontributors. This vote is based on the technical stability of the new
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowecode and the stability of the interface. Once moved to stable, that feature
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowecannot change for the remainder of that lifetime of that stable verions,
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweso the vote must reflect that the final decisions on the behavior and naming
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweof that new feature were reached. Vetos continue to apply to this choice
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweof introducing the new work to the stable version.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweAt any given time, when the quality of changes to the development branch
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweis considered release quality, that version may become a candidate for the
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowenext stable release. This includes some or all of the API changes, promoting
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweexperimental modules to stable or deprecating and eliminating older modules
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowefrom the last stable release. All of these choices are considered by the
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweproject as a group in the interests of promoting the stable release, so that
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweany given change may be 'deferred' for a future release by the group, rather
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowethan introduce unacceptable risks to adopting the next stable release.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweThird party module authors are strongly encouraged to test with the latest
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowedevelopment version. This assures that the module will be ready for the next
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowestable release, but more importantly, the author can react to shortcomings
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowein the API early enough to warn the dev@httpd.apache.org community of the
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweshortcomings so that they can be addressed before the stable release. The
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweentire onus is on the third party module author to anticipate the needs of
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowetheir module before the stable release is created, once it has been released
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowethey will be stuck with that API for the lifetime of that stable release.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wroweWORKS IN PROGRESS
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe-----------------
a601d863bd772fefc4dc82a883589d8be6a44811wrowe
a601d863bd772fefc4dc82a883589d8be6a44811wrowe * Source code should follow style guidelines.
a601d863bd772fefc4dc82a883589d8be6a44811wrowe OK, we all agree pretty code is good. Probably best to clean this
a601d863bd772fefc4dc82a883589d8be6a44811wrowe up by hand immediately upon branching a 2.1 tree.
6f51bbc3054846e0c0a897d5f16ceba1726bebc6jerenkrantz Status: Justin volunteers to hand-edit the entire source tree ;)
6f51bbc3054846e0c0a897d5f16ceba1726bebc6jerenkrantz
6f51bbc3054846e0c0a897d5f16ceba1726bebc6jerenkrantz Justin says:
6f51bbc3054846e0c0a897d5f16ceba1726bebc6jerenkrantz Recall when the release plan for 2.0 was written:
6f51bbc3054846e0c0a897d5f16ceba1726bebc6jerenkrantz Absolute Enforcement of an "Apache Style" for code.
6f51bbc3054846e0c0a897d5f16ceba1726bebc6jerenkrantz Watch this slip into 3.0.
a601d863bd772fefc4dc82a883589d8be6a44811wrowe
ff920f8ae37ba372801b67ea7c3d5bf1dfb55585dreid David says:
ff920f8ae37ba372801b67ea7c3d5bf1dfb55585dreid The style guide needs to be reviewed before this can be done.
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe http://httpd.apache.org/dev/styleguide.html
ff920f8ae37ba372801b67ea7c3d5bf1dfb55585dreid The current file is dated April 20th 1998!
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe OtherBill offers:
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe It's survived since '98 because it's welldone :-) Suggest we
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe simply follow whatever is documented in styleguide.html as we
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe branch the next tree. Really sort of straightforward, if you
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe dislike a bit within that doc, bring it up on the dev@httpd
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe list prior to the next branch.
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe So Bill sums up ... let's get the code cleaned up in CVS head.
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe Remember, it just takes cvs diff -b (that is, --ignore-space-change)
998d56ea74f8cc733b423da076dadb0fd0a789f3wrowe to see the code changes and ignore that cruft. Get editing Justin :)
ff920f8ae37ba372801b67ea7c3d5bf1dfb55585dreid
a601d863bd772fefc4dc82a883589d8be6a44811wrowe * revamp the input filter syntax to provide for ordering of
a601d863bd772fefc4dc82a883589d8be6a44811wrowe filters created with the Set{Input|Output}Filter and the
a601d863bd772fefc4dc82a883589d8be6a44811wrowe Add{Input|Output}Filter directives. A 'relative to filterx'
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe syntax is definately preferable.
a601d863bd772fefc4dc82a883589d8be6a44811wrowe
a601d863bd772fefc4dc82a883589d8be6a44811wrowe * Platforms that do not support fork (primarily Win32 and AS/400)
a601d863bd772fefc4dc82a883589d8be6a44811wrowe Architect start-up code that avoids initializing all the modules
a601d863bd772fefc4dc82a883589d8be6a44811wrowe in the parent process on platforms that do not support fork.
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe . Better yet - not only inform the startup of which phase it's in,
a601d863bd772fefc4dc82a883589d8be6a44811wrowe but allow the parent 'process' to initialize shared memory, etc,
a601d863bd772fefc4dc82a883589d8be6a44811wrowe and create a module-by-module stream to pass to the child, so the
a601d863bd772fefc4dc82a883589d8be6a44811wrowe parent can actually arbitrate the important stuff.
a601d863bd772fefc4dc82a883589d8be6a44811wrowe
a601d863bd772fefc4dc82a883589d8be6a44811wrowe * Replace stat [deferred open] with open/fstat in directory_walk.
a601d863bd772fefc4dc82a883589d8be6a44811wrowe Justin, Ian, OtherBill all interested in this. Implies setting up
a601d863bd772fefc4dc82a883589d8be6a44811wrowe the apr_file_t member in request_rec, and having all modules use
a601d863bd772fefc4dc82a883589d8be6a44811wrowe that file, and allow the cleanup to close it [if it isn't a shared,
a601d863bd772fefc4dc82a883589d8be6a44811wrowe cached file handle.]
a601d863bd772fefc4dc82a883589d8be6a44811wrowe
a601d863bd772fefc4dc82a883589d8be6a44811wrowe * The Async Apache Server implemented in terms of APR.
a601d863bd772fefc4dc82a883589d8be6a44811wrowe [Bill Stoddard's pet project.]
fc9e01023a2fb7f7af9b25621ab080bbe7a95611jerenkrantz Message-ID: <008301c17d42$9b446970$01000100@sashimi> (dev@apr)
a601d863bd772fefc4dc82a883589d8be6a44811wrowe
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe OtherBill notes that this can proceed in two parts...
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe Async accept, setup, and tear-down of the request
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe e.g. dealing with the incoming request headers, prior to
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe dispatching the request to a thread for processing.
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe This doesn't need to wait for a 2.x/3.0 bump.
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe Async delegation of the entire request processing chain
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe Too many handlers use stack storage and presume it is
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe available for the life of the request, so a complete
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe async implementation would need to happen 3.0 release.
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe
bfae8a5d3c37df19dea49b411b109198c7e84a4fbrianp * Add a string "class" that combines a char* with a length
bfae8a5d3c37df19dea49b411b109198c7e84a4fbrianp and a reference count. This will help reduce the number
bfae8a5d3c37df19dea49b411b109198c7e84a4fbrianp of strlen and strdup operations during request processing.
7dfb10a15cdfd48a23a9aa5713a2deb129821761wrowe Including both the length and allocation will save us a ton
7dfb10a15cdfd48a23a9aa5713a2deb129821761wrowe of reallocation we do today, in terms of string manipulation.
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe
998a0c99bc22357406f359ace2f602c5d6e376c6wrowe OtherBill asks if this is really an APR issue, not an HTTPD issue?
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gsteinMAKING APACHE REPOSITORY-AGNOSTIC
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein(or: remove knowledge of the filesystem)
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein[ 2002/10/01: discussion in progress on items below; this isn't
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein planned yet ]
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein * dav_resource concept for an HTTP resource ("ap_resource")
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein * r->filename, r->canonical_filename, r->finfo need to
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein disappear. All users need to use new APIs on the ap_resource
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein object.
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein (backwards compat: today, when this occurs with mod_dav and a
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein custom backend, the above items refer to the topmost directory
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein mapped by a location; e.g. docroot)
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe Need to preserve a 'filename'-like string for mime-by-name
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe sorts of operations. But this only needs to be the name itself
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe and not a full path.
29b927351fa38aca768d31d70116acd0a71ed415jerenkrantz
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein Justin: Can we leverage the path info, or do we not trust the
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein user?
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein gstein: well, it isn't the "path info", but the actual URI of
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein the resource. And of course we trust the user... that is
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein the resource they requested.
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein dav_resource->uri is the field you want. path_info might
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein still exist, but that portion might be related to the
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein CGI concept of "path translated" or some other further
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein resolution.
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein To continue, I would suggest that "path translated" and
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein having *any* path info is Badness. It means that you did
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein not fully resolve a resource for the given URI. The
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein "abs_path" in a URI identifies a resource, and that
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein should get fully resolved. None of this "resolve to
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein <here> and then we have a magical second resolution
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein (inside the CGI script)" or somesuch.
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz Justin: Well, let's consider mod_mbox for a second. It is sort of
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz a virtual filesystem in its own right - as it introduces
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz it's own notion of a URI space, but it is intrinsically
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz tied to the filesystem to do the lookups. But, for the
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz portion that isn't resolved on the file system, it has
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz its own addressing scheme. Do we need the ability to
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz layer resolution?
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein * The translate_name hook goes away
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe Wrowe altogether disagrees. translate_name today even operates
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe on URIs ... this mechansim needs to be preserved.
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein * The doc for map_to_storage is totally opaque to me. It has
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein something to do with filesystems, but it also talks about
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein security and per_dir_config and other stuff. I presume something
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein needs to happen there -- at least better doc.
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe Wrowe agrees and will write it up.
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein * The directory_walk concept disappears. All configuration is
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein tagged to Locations. The "mod_filesystem" module might have some
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein internal concept of the same config appearing in multiple
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein places, but that is handled internally rather than by Apache
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein core.
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe Wrowe suggests this is wrong, instead it's private to filesystem
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe requests, and is already invoked from map_to_storage, not the core
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe handler. <Directory > and <Files > blocks are preserved as-is,
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe but <Directory > sections become specific to the filesystem handler
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe alone. Because alternate filesystem schemes could be loaded, this
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe should be exposed, from the core, for other file-based stores to
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe share. Consider an archive store where the layers become
cdc56e100a8fa11e989d1633914502db1c8e0818wrowe <Directory path> -> <Archive store> -> <File name>
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz Justin: How do we map Directory entries to Locations?
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein * The "Location tree" is an in-memory representation of the URL
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein namespace. Nodes of the tree have configuration specific to that
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein location in the namespace.
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein Something like:
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein typedef struct {
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein const char *name; /* name of this node relative to parent */
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
10a6f4803b893e9e77f5ad60ccb387ca1a15f84djerenkrantz struct ap_conf_vector_t *locn_config;
10a6f4803b893e9e77f5ad60ccb387ca1a15f84djerenkrantz
10a6f4803b893e9e77f5ad60ccb387ca1a15f84djerenkrantz apr_hash_t *children; /* NULL if no child configs */
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein } ap_locn_node;
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein The following config:
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein <Location /server-status>
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein SetHandler server-status
10a6f4803b893e9e77f5ad60ccb387ca1a15f84djerenkrantz Order deny,allow
10a6f4803b893e9e77f5ad60ccb387ca1a15f84djerenkrantz Deny from all
10a6f4803b893e9e77f5ad60ccb387ca1a15f84djerenkrantz Allow from 127.0.0.1
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein </Location>
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein Creates a node with name=="server_status", and the node is a
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein child of the "/" node. (hmm. node->name is redundant with the
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein hash key; maybe drop node->name)
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein In the config vector, mod_access has stored its Order, Deny, and
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein Allow configs. mod_core has stored the SetHandler.
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein During the Location walk, we merge the config vectors normally.
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein Note that an Alias simply associates a filesystem path (in
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein mod_filesystem) with that Location in the tree. Merging
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein continues with child locations, but a merge is never done
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein through filesystem locations. Config on a specific subdir needs
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein to be mapped back into the corresponding point in the Location
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein tree for proper merging.
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein * Config is parsed into a tree, as we did for the 2.0 timeframe,
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein but that tree is just a representation of the config (for
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein multiple runs and for in-memory manipulation and usage). It is
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein unrelated to the "Location tree".
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein * Calls to apr_file_io functions generally need to be replaced
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein with operations against the ap_resource. For example, rather
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein than calling apr_dir_open/read/close(), a caller uses
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein resource->repos->get_children() or somesuch.
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein Note that things like mod_dir, mod_autoindex, and mod_negotation
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein need to be converted to use these mechanisms so that their
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein functions will work on logical repositories rather than just
27ddebab333df2a3d82b0f4ea63878d1d9f38ae8gstein filesystems.
29b927351fa38aca768d31d70116acd0a71ed415jerenkrantz
29b927351fa38aca768d31d70116acd0a71ed415jerenkrantz * How do we handle CGI scripts? Especially when the resource may
29b927351fa38aca768d31d70116acd0a71ed415jerenkrantz not be backed by a file? Ideally, we should be able to come up
29b927351fa38aca768d31d70116acd0a71ed415jerenkrantz with some mechanism to allow CGIs to work in a
29b927351fa38aca768d31d70116acd0a71ed415jerenkrantz repository-independent manner.
29b927351fa38aca768d31d70116acd0a71ed415jerenkrantz
29b927351fa38aca768d31d70116acd0a71ed415jerenkrantz - Writing the virtual data as a file and then executing it?
29b927351fa38aca768d31d70116acd0a71ed415jerenkrantz - Can a shell be executed in a streamy manner? (Portably?)
29b927351fa38aca768d31d70116acd0a71ed415jerenkrantz - Have an 'execute_resource' hook/func that allows the
29b927351fa38aca768d31d70116acd0a71ed415jerenkrantz repository to choose its manner - be it exec() or whatever.
29b927351fa38aca768d31d70116acd0a71ed415jerenkrantz - Won't this approach lead to duplication of code? Helper fns?
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein gstein: PHP, Perl, and Python scripts are nominally executed by
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein a filter inserted by mod_php/perl/python. I'd suggest
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein that shell/batch scripts are similar.
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein But to ask further: what if it is an executable
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein *program* rather than just a script? Do we yank that out
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein of the repository, drop it onto the filesystem, and run
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein it? eeewwwww...
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein
39d8628e74736d0bd8c4114d8e615dffa8fbbcf7gstein I'll vote -0.9 for CGIs as a filter. Keep 'em handlers.
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz Justin: So, do we give up executing CGIs from virtual repositories?
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz That seems like a sad tradeoff to make. I'd like to have
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz my CGI scripts under DAV (SVN) control.
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz * How do we handle overlaying of Location and Directory entries?
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz Right now, we have a problem when /cgi-bin/ is ScriptAlias'd and
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz mod_dav has control over /. Some people believe that /cgi-bin/
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz shouldn't be under DAV control, while others do believe it
bb16031776199a40aa54b2a6540835f7f8db0ce8jerenkrantz should be. What's the right strategy?