RE: cvs commit: httpd-2.0/server core.c request.c
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 3:25 AM striker 2003/06/30 18:25:07 Modified:.Tag: APACHE_2_0_BRANCH CHANGES STATUS include Tag: APACHE_2_0_BRANCH http_core.h modules/http Tag: APACHE_2_0_BRANCH http_request.c server Tag: APACHE_2_0_BRANCH core.c request.c Removed: buildTag: APACHE_2_0_BRANCH httpd_roll_release Whoops! Well, the thing had to go some day, because I don't want someone making the mistake of using it anymore. It wasn't supposed to go in this commit though. Sorry for the noise. Sander
Re: cvs commit: httpd-2.0/server core.c request.c util.c
William A. Rowe, Jr. wrote: The configuration and context below seems odd to me; : You haven't resolved any Directory, Files, Locations etc in the code fragment above... it's too early in the request processing cycle. It seems this should not be a dir_conf flag, but actually a server_conf flag since your patch only resolves the directive relative to a given server. that's right, i didn't. as explained earlier, this is currently RSRC_CONF, which means it *can't* appear in any of those containers, so that point is moot. that makes it essentially server-scope -- but by treating it as per-dir now, we don't need to shift from per-server to per-dir when we have a more finely grained solution. And what is the impact of this patch on proxies and using mod_rewrite to proxy certain URIs? i will investigate. i'm tempted to consider this a piece of rope, however, and as long as it doesn't open any security exposures, caveat emptor. It would be best if we unparsed and tracked the offsets in the source and unescaped query strings of individual components (scheme, user, host, path, path_info and query). We could do something as simple as counting the number of slashes in the source and target paths, and failing only when those two components mismatch. this has been mentioned several times as a 'gee, it would be nice.' unfortunately, it is also a major hassle due to all the rewriting potential, et cetera. it's definitely for later. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp!
Re: cvs commit: httpd-2.0/server core.c request.c util.c
coar2003/01/23 13:34:14
Modified:include ap_mmn.h http_core.h httpd.h
server core.c request.c util.c
Log:
here we go. add a directive that will keep %2f from being
decoded into '/', allowing the *_walk to do their magic and
return 404 if it's in the path, and allowing it in the path-info.
The configuration and context below seems odd to me;
--- core.c18 Jan 2003 03:37:54 - 1.229
+++ core.c23 Jan 2003 21:34:13 - 1.230
@@ -3054,6 +3070,8 @@
AP_INIT_ITERATE2(AddOutputFilterByType, add_ct_output_filters,
(void *)APR_OFFSETOF(core_dir_config, ct_output_filters), OR_FILEINFO,
output filter name followed by one or more content-types),
+AP_INIT_FLAG(AllowEncodedSlashes, set_allow2f, NULL, RSRC_CONF,
+ Allow URLs containing '/' encoded as '%2F'),
--- request.c 12 Dec 2002 07:05:54 - 1.122
+++ request.c 23 Jan 2003 21:34:13 - 1.123
@@ -147,13 +147,22 @@
/* Ignore embedded %2F's in path for proxy requests */
if (!r-proxyreq r-parsed_uri.path) {
-access_status = ap_unescape_url(r-parsed_uri.path);
+core_dir_config *d;
+d = ap_get_module_config(r-per_dir_config, core_module);
+if (d-allow_encoded_slashes) {
+access_status = ap_unescape_url_keep2f(r-parsed_uri.path);
+}
+else {
+access_status = ap_unescape_url(r-parsed_uri.path);
+}
You haven't resolved any Directory, Files, Locations etc in the
code fragment above... it's too early in the request processing cycle.
It seems this should not be a dir_conf flag, but actually a server_conf flag
since your patch only resolves the directive relative to a given server.
Does this make sense?
And what is the impact of this patch on proxies and using mod_rewrite
to proxy certain URIs? It seems folks have %2f's popping up more and
more often in their query args - and we have a number of much more
pressing bugs that the query /foo?answer=yes%2fno would be discarded.
Usually, path_info is under the web developer's control - but the query
string is rarely in our control, but the users/browsers' control.
I'm afraid that the proxied flavor of this would result in ?answer=yes%2fno
which would be re-escaped to the backend server or redirect as something
like ?answer=yes%252fno which would be a real problem.
It would be good to come up with a schema where the unparse/parse would
actually be their reciprocals.
It would be better if unparse/parse would respect the query_args and be
just a little more tolerant of %2f once the path is complete and the query
string begins.
It would be best if we unparsed and tracked the offsets in the source and
unescaped query strings of individual components (scheme, user, host,
path, path_info and query). We could do something as simple as counting
the number of slashes in the source and target paths, and failing only when
those two components mismatch.
Bill
Re: cvs commit: httpd-2.0/server core.c request.c util.c
* [EMAIL PROTECTED] wrote:
Index: ap_mmn.h
===
RCS file: /home/cvs/httpd-2.0/include/ap_mmn.h,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -u -r1.52 -r1.53
--- ap_mmn.h3 Sep 2002 23:39:43 - 1.52
+++ ap_mmn.h23 Jan 2003 21:34:12 - 1.53
@@ -111,6 +111,7 @@
* 20020625 (2.0.40-dev) Changed conn_rec-keepalive to an enumeration
* 20020628 (2.0.40-dev) Added filter_init to filter registration functions
* 20020903 (2.0.41-dev) APR's error constants changed
+ * 20020903.1 (2.0.44-dev) allow_encoded_slashes added to core_dir_config
This should now be 2.0.45-dev, shouldn't it?
nd
--
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~ # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=map{chr(ord( # André Malo ;
$_)-1)}split//=$_[0]).$_[1];s s.*s$_see; # http://www.perlig.de/ ;
Re: cvs commit: httpd-2.0/server core.c request.c util.c
* Justin Erenkrantz wrote: --On Friday, January 24, 2003 00:11:22 +0100 André Malo [EMAIL PROTECTED] wrote: + * 20020903.1 (2.0.44-dev) allow_encoded_slashes added to core_dir_config This should now be 2.0.45-dev, shouldn't it? 2.1.0-dev. -- justin *err* yes ... nd -- die (eval q-qq:Just Another Perl Hacker :-) # André Malo, http://www.perlig.de/ #
Re: cvs commit: httpd-2.0/server core.c request.c
brianp 01/12/31 00:18:32
Modified:include http_core.h
server core.c request.c
Log:
Performance fix for prep_walk_cache():
Moved the directory/location/file-walk caches from the
request's pool userdata hash table to the core_request_config
struct.
This change removes about 60% of the processing time from
prep_walk_cache().
Brian... this is a very cool patch...
+typedef enum {
+AP_WALK_DIRECTORY,
+AP_WALK_LOCATION,
+AP_WALK_FILE,
+AP_NUM_WALK_CACHES
+} ap_walk_cache_type;
+
typedef struct {
/* bucket brigade used by getline for look-ahead and
* ap_get_client_block for holding left-over request body */
struct apr_bucket_brigade *bb;
+
+/* a place to hold per-request working data for
+ * ap_directory_walk, ap_location_walk, and ap_file_walk */
+void *walk_cache[AP_NUM_WALK_CACHES];
} core_request_config;
However, can we find a way to make AP_NUM_WALK_CACHES a bit more flexible?
See, for example, mod_proxy. We are doing the same bit there. Would you
mind extending your patch to allow registration [at startup] of other
cache members? This could be used for walk caches, or for other sorts of
per-request cached data that currently resides in notes (and should reside
in userdata, until you pointed out how slow that solution really is.)
In any case, nice work :)
Bill
Re: cvs commit: httpd-2.0/server core.c request.c
William A. Rowe, Jr. wrote: ... However, can we find a way to make AP_NUM_WALK_CACHES a bit more flexible? See, for example, mod_proxy. We are doing the same bit there. Would you mind extending your patch to allow registration [at startup] of other cache members? This could be used for walk caches, or for other sorts of per-request cached data that currently resides in notes (and should reside in userdata, until you pointed out how slow that solution really is.) I like the registration idea. I'll work out an API for it sometime this week. --Brian
Re: cvs commit: httpd-2.0/server core.c request.c
On Sun, Aug 26, 2001 at 05:10:17AM -, [EMAIL PROTECTED] wrote:
core_a = ap_get_module_config(a-elt, core_module);
core_b = ap_get_module_config(b-elt, core_module);
-if (IS_SPECIAL(core_a)) {
- if (!IS_SPECIAL(core_b)) {
- return 1;
- }
+
+if (core_a-r core_b-r) {
+return -1;
}
-else if (IS_SPECIAL(core_b)) {
- return -1;
+else if (core_a-r core_b-r) {
+return 1;
}
Does this bit mean that regex-based sections won't run in config-file
order, but in order of their positions in the heap?
-else {
- /* we know they're both not special */
- if (core_a-d_components core_b-d_components) {
- return -1;
- }
- else if (core_a-d_components core_b-d_components) {
- return 1;
- }
+if (core_a-d_components core_b-d_components) {
+return -1;
+}
+else if (core_a-d_components core_b-d_components) {
+return 1;
}
-/* Either they're both special, or they're both not special and have the
- * same number of components. In any event, we now have to compare
- * the minor key. */
+/* They have the same number of components, we now have to compare
+ * the minor key to maintain the original order.
+ */
return a-orig_index - b-orig_index;
}
Re: cvs commit: httpd-2.0/server core.c request.c
From: Barrie Slaymaker [EMAIL PROTECTED]
Sent: Monday, August 27, 2001 3:22 AM
On Sun, Aug 26, 2001 at 05:10:17AM -, [EMAIL PROTECTED] wrote:
core_a = ap_get_module_config(a-elt, core_module);
core_b = ap_get_module_config(b-elt, core_module);
-if (IS_SPECIAL(core_a)) {
- if (!IS_SPECIAL(core_b)) {
- return 1;
- }
+
+if (core_a-r core_b-r) {
+return -1;
}
-else if (IS_SPECIAL(core_b)) {
- return -1;
+else if (core_a-r core_b-r) {
+return 1;
}
Does this bit mean that regex-based sections won't run in config-file
order, but in order of their positions in the heap?
They always have run in this order,
1. Non regex expressions first, then all regex'es
2. By the number of components (so '/', then '/foo', then '/foo/bar')
3. By their order in the configuration file.
The only thing this patch changes is that 'specials' (such as proxy: entries)
cannot be in Directory sections. The proxy: entries can now be configured
with Proxy sections. And my patch to run Proxy entries doesn't sort them
at all (I have posted the question to the modproxy-dev list, if we even want
them sorted by any critera.)
Bill
Re: cvs commit: httpd-2.0/server core.c request.c
On Mon, Aug 27, 2001 at 07:22:52AM -0500, William A. Rowe, Jr. wrote:
From: Barrie Slaymaker [EMAIL PROTECTED]
Sent: Monday, August 27, 2001 3:22 AM
On Sun, Aug 26, 2001 at 05:10:17AM -, [EMAIL PROTECTED] wrote:
core_a = ap_get_module_config(a-elt, core_module);
core_b = ap_get_module_config(b-elt, core_module);
-if (IS_SPECIAL(core_a)) {
- if (!IS_SPECIAL(core_b)) {
- return 1;
- }
+
+if (core_a-r core_b-r) {
+return -1;
}
-else if (IS_SPECIAL(core_b)) {
- return -1;
+else if (core_a-r core_b-r) {
+return 1;
}
Does this bit mean that regex-based sections won't run in config-file
order, but in order of their positions in the heap?
They always have run in this order,
1. Non regex expressions first, then all regex'es
2. By the number of components (so '/', then '/foo', then '/foo/bar')
3. By their order in the configuration file.
#3 is why I responded. This patch seems to change that nice behavior;
like regexes are sorted by their addresses (the value of core_{a,b}-r)
rather than their position (core_{a,b}-orig_index).
The only thing this patch changes is that 'specials' (such as proxy: entries)
cannot be in Directory sections. The proxy: entries can now be configured
with Proxy sections. And my patch to run Proxy entries doesn't sort them
at all (I have posted the question to the modproxy-dev list, if we even want
them sorted by any critera.)
Yup, I like the Proxy section stuff a lot.
As far as sorting, it would be nice for everyone's sanity if
(Directory|Location|Proxy)(Match)? sections were sorted using as
similar a logic as possible. Given the number of incremental directives
that are starting to crop up, sort order is going to be very important
to config stability. By incremental directives, I mean directives where
previous settings are modified by directives occuring in later directory
sections, like the (unintuitively named, IMHO) Set{Input,Output}Filter
and like external modules do (see AxKit's directives for a lot of
these).
Just the ramblings of someone who's had to explain the current state of
affairs and watch the heads shaking...
- Barrie
P.S. I also like the suggestion that went by to make the first
ap_location_walk stick and do away with the second. It's much more
intuitive to me: URIs get run through the Location mill first, then
(Directory and Files) or (Proxy) section. Seems like the need for
the duplicate ap_location_walk()s should be much less now that PRosy
sections exist.
Re: cvs commit: httpd-2.0/server core.c request.c
On Monday 27 August 2001 06:22, Bill Stoddard wrote: From: Bill Stoddard [EMAIL PROTECTED] Sent: Sunday, August 26, 2001 11:48 AM On Sat, Aug 25, 2001 at 11:43:19PM -, [EMAIL PROTECTED] wrote: wrowe 01/08/25 16:43:19 Modified:.CHANGES include http_request.h modules/http http_core.c http_protocol.c http_request.c mod_core.h server core.c request.c Log: Introduce the map_to_storage hook, which allows modules to bypass the directory_walk and file_walk for non-file requests. TRACE How is this different from the translate_name hook? Your new hook and the translate_name are both about translating URLs into the backend storage. Why was this new one added? (did I miss some discussion somewhere?) And if so, then why does translate_name stick around? Sounds similar to the quick_handler hook as well. It does? Then you need to find a clue. quick_handler should have been axed from the outset, and now that this handler allows a non-filesystem request to be handled properly, it really should be gone. map_to_storage is definitely not the same as quick_handler. But quick_handler does have a use so it stays in. Actually, they are closer than you might think. quick_handler's purpose is to allow requests to be served as quickly as possible. It skips a lot of phases of the request to accomplish that. If map_to_storage is tweaked a bit, it can accomplish the same thing. Basically, the map_to_storage function that succeeds would tell the server how many of the hooks that follow map_to_storage that it should skip before the handler phase. This has a couple of advantages over quick_handler, the first one being that it is more general, and the second that it means we go back to having one location that data is sent to the network. If that change is made to map_to_storage, then I would be with OtherBill, and suggest that quick_handler should be removed. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0/server core.c request.c
It does? Then you need to find a clue. quick_handler should have been axed from the outset, and now that this handler allows a non-filesystem request to be handled properly, it really should be gone. map_to_storage is definitely not the same as quick_handler. But quick_handler does have a use so it stays in. Actually, they are closer than you might think. quick_handler's purpose is to allow requests to be served as quickly as possible. It skips a lot of phases of the request to accomplish that. If map_to_storage is tweaked a bit, it can accomplish the same thing. Basically, the map_to_storage function that succeeds would tell the server how many of the hooks that follow map_to_storage that it should skip before the handler phase. This has a couple of advantages over quick_handler, the first one being that it is more general, and the second that it means we go back to having one location that data is sent to the network. If that change is made to map_to_storage, then I would be with OtherBill, and suggest that quick_handler should be removed. Give me a while to experiment with getting mod_cache working with map_to_storage. I've been considering moving quick_handler to after the first Location walk, which brings the functionality I am looking for very close to map_to_storage. We are meeting in the middle :-) Bill
Re: cvs commit: httpd-2.0/server core.c request.c
From: Barrie Slaymaker [EMAIL PROTECTED]
Sent: Monday, August 27, 2001 8:22 AM
On Mon, Aug 27, 2001 at 07:22:52AM -0500, William A. Rowe, Jr. wrote:
From: Barrie Slaymaker [EMAIL PROTECTED]
Sent: Monday, August 27, 2001 3:22 AM
On Sun, Aug 26, 2001 at 05:10:17AM -, [EMAIL PROTECTED] wrote:
core_a = ap_get_module_config(a-elt, core_module);
core_b = ap_get_module_config(b-elt, core_module);
-if (IS_SPECIAL(core_a)) {
- if (!IS_SPECIAL(core_b)) {
- return 1;
- }
+
+if (core_a-r core_b-r) {
+return -1;
}
-else if (IS_SPECIAL(core_b)) {
- return -1;
+else if (core_a-r core_b-r) {
+return 1;
}
Does this bit mean that regex-based sections won't run in config-file
order, but in order of their positions in the heap?
They always have run in this order,
1. Non regex expressions first, then all regex'es
2. By the number of components (so '/', then '/foo', then '/foo/bar')
3. By their order in the configuration file.
#3 is why I responded. This patch seems to change that nice behavior;
like regexes are sorted by their addresses (the value of core_{a,b}-r)
rather than their position (core_{a,b}-orig_index).
OUTCH! It does, thank you!
if ((core_a-r != NULL) (core_b-r != NULL)) {
return -1;
}
else if ((core_a-r != NULL) (core_b-r != NULL)) {
return 1;
}
does that look better :-? I'll commit as soon as someone tells me sanity (or at least
my abuse of pointers as bools) is cured :)
Bill
The only thing this patch changes is that 'specials' (such as proxy: entries)
cannot be in Directory sections. The proxy: entries can now be configured
with Proxy sections. And my patch to run Proxy entries doesn't sort them
at all (I have posted the question to the modproxy-dev list, if we even want
them sorted by any critera.)
Yup, I like the Proxy section stuff a lot.
As far as sorting, it would be nice for everyone's sanity if
(Directory|Location|Proxy)(Match)? sections were sorted using as
similar a logic as possible. Given the number of incremental directives
that are starting to crop up, sort order is going to be very important
to config stability. By incremental directives, I mean directives where
previous settings are modified by directives occuring in later directory
sections, like the (unintuitively named, IMHO) Set{Input,Output}Filter
and like external modules do (see AxKit's directives for a lot of
these).
Just the ramblings of someone who's had to explain the current state of
affairs and watch the heads shaking...
- Barrie
P.S. I also like the suggestion that went by to make the first
ap_location_walk stick and do away with the second. It's much more
intuitive to me: URIs get run through the Location mill first, then
(Directory and Files) or (Proxy) section. Seems like the need for
the duplicate ap_location_walk()s should be much less now that PRosy
sections exist.
Re: cvs commit: httpd-2.0/server core.c request.c
From: Ryan Bloom [EMAIL PROTECTED] Sent: Monday, August 27, 2001 8:41 AM map_to_storage is definitely not the same as quick_handler. But quick_handler does have a use so it stays in. Actually, they are closer than you might think. quick_handler's purpose is to allow requests to be served as quickly as possible. It skips a lot of phases of the request to accomplish that. If map_to_storage is tweaked a bit, it can accomplish the same thing. It's not going to be tweaked (you security sloths, you :) We need to look at each of the hook phases, and figure out how a module can selectively bypass that hook, when it should, and why. I'll probably start a paper detailing how the current Apache system exposes hooks, and what's the harm in using/bypassing those hooks. Quick_handler bypasses everything. We ignore the client's headers, the server's configuration, everything. Frankly, quick_handler is not Apache, and anyone who writes a quick_handler hack and calls it a module for 'Apache' is full of sh*t. Powered by the Apr/Apache MPM/load manager is more like it (that isn't badness, that's just reality.) Basically, the map_to_storage function that succeeds would tell the server how many of the hooks that follow map_to_storage that it should skip before the handler phase. No... I thought long and hard about that, and I dislike it. It's full of opportunities to mess up security and bypass things you didn't expect (in v. 2.1 or whenever.) hook_to_storage (named wrong, we agree) is the trap to walk a set of dir_config's that are customized for the module. 50% of the modules serve files, so they _don't_ hook this call. 40% of the modules invent content in a yes or no sort of way. They are generally driven by the Location block, so that block can contain their access restrictions. They don't want us to hook up any extra dir_config's, so they may hook this call and just return OK. 10% of the modules (e.g. proxy, perhaps a database-driven content store) don't have 'files' in the traditional sense, but they want a tree mapping of restrictions, and it won't correspond to our Directory Files sections in a 1:1 manner. For those modules, they can hook and replace dir_walk/file_walk with their own (e.g. proxy_walk.) This has a couple of advantages over quick_handler, the first one being that it is more general, and the second that it means we go back to having one location that data is sent to the network. Yes - it's definately a design decision that an author needs to be aware of. We aren't working well enough with too many modules as it is (take mod_autoindex/negotation/mime security reports, or tomcat security reports.) We don't want module authors to suffer from a slow model. But we don't want them wandering too far out of the fold, until they fall in the pit that so many modules have landed in. If that change is made to map_to_storage, then I would be with OtherBill, and suggest that quick_handler should be removed. I'm about to suggest that as well, but I don't think we can do so until we optimize our whole server. That is, I just optimized the two-pass Location parsing. Unless the URI is remapped (a significant context change that requires rewalking the location), or we have been mapped to a virtual server with a different set of locations (they probably wern't inherited from the base server), then we will do zero or one directory merges. Zero merges if no module modified the per_dir_config since we left it (no dir/file/proxy walk), or one merge if we see someone reset per_dir_config, so we will overlay it. Almost every hook can be a bit more optimized this way. I'm most concerned about subreq and internal redirect mechansims, and will continue to work to assure 1. they do the same thing, even in different contexts, and 2. they rely on the original request as much as possible to drop cpu/filesystem load. An example ... dir_walk can do the same thing as location_walk does. If we already walked the first 3 directory elements, and come back with a subreq for a subdir, why duplicate the work? We have some great opportunities here for cleaner, smaller and faster code. Then I'll suggest dropping quick_handler, and have a document to back up my position :) Bill
Re: cvs commit: httpd-2.0/server core.c request.c
map_to_storage is definitely not the same as quick_handler. But quick_handler does have a use so it stays in. Actually, they are closer than you might think. quick_handler's purpose is to allow requests to be served as quickly as possible. It skips a lot of phases of the request to accomplish that. If map_to_storage is tweaked a bit, it can accomplish the same thing. It's not going to be tweaked (you security sloths, you :) We need to look at each of the hook phases, and figure out how a module can selectively bypass that hook, when it should, and why. I'll probably start a paper detailing how the current Apache system exposes hooks, and what's the harm in using/bypassing those hooks. Quick_handler bypasses everything. We ignore the client's headers, the server's configuration, everything. Frankly, quick_handler is not Apache, and anyone who writes a quick_handler hack and calls it a module for 'Apache' is full of sh*t. Powered by the Apr/Apache MPM/load manager is more like it (that isn't badness, that's just reality.) So tell us how you -really- feel :-) I am looking at the map_to_storage hook to see how it works. Stay tuned. The quick_handler hook was named after (and is used by) Mike Abbott's quick cache, an -Apache- module. It is a specialized hook to serve a specialized purpose: serving web pages as fast as possible from a user space resident cache. And it can be used without compromising the security of the server. Bill
Re: cvs commit: httpd-2.0/server core.c request.c
From: Bill Stoddard [EMAIL PROTECTED] Sent: Monday, August 27, 2001 10:54 AM map_to_storage is definitely not the same as quick_handler. But quick_handler does have a use so it stays in. Actually, they are closer than you might think. quick_handler's purpose is to allow requests to be served as quickly as possible. It skips a lot of phases of the request to accomplish that. If map_to_storage is tweaked a bit, it can accomplish the same thing. Quick_handler bypasses everything. We ignore the client's headers, the server's configuration, everything. Frankly, quick_handler is not Apache, and anyone who writes a quick_handler hack and calls it a module for 'Apache' is full of sh*t. Powered by the Apr/Apache MPM/load manager is more like it (that isn't badness, that's just reality.) So tell us how you -really- feel :-) Let me fine-tune my statement. Modules that use quick_handler bypass the _user's_ expectations, and our documented behavior. If this is ok for a given module, and is well documented, then fine. I feel that nothing frustrates me more, personally, than to follow docs and observe a different result than was doumented. That's why I turned Greg to the Location /Limit combinations for DAV, since they have odd side-effects. I am looking at the map_to_storage hook to see how it works. Stay tuned. The quick_handler hook was named after (and is used by) Mike Abbott's quick cache, an -Apache- module. It is a specialized hook to serve a specialized purpose: serving web pages as fast as possible from a user space resident cache. And it can be used without compromising the security of the server. The best example is loading the mod_proxy/proxy_http combination. I have to say that the patch to mod_proxy was about as clear as I've ever written. It will give you a terrific feel for what can be done :) From an optimization perspective, see the Location patch from last night, it shows what you can do with pre-cached per_dir_config's, you would just need to use config wide pools and voila, mod_file_cache can have preconstructed per_dir_configs too. I'll be modifying Directory to also observe any preconstruction, so all internal_internal_redirect and subreq entities can go back through directory_walk without consuming significant CPU. Bill
Re: cvs commit: httpd-2.0/server core.c request.c
On Mon, Aug 27, 2001 at 09:47:28AM -0500, William A. Rowe, Jr. wrote:
if ((core_a-r != NULL) (core_b-r != NULL)) {
return -1;
}
else if ((core_a-r != NULL) (core_b-r != NULL)) {
return 1;
}
does that look better :-? I'll commit as soon as someone tells me sanity (or at
least
my abuse of pointers as bools) is cured :)
Ack, my C is getting too rusty. I seem to recall that (1 0) (0 1)
not portable. Perhaps the
if ((core_a-r == NULL) (core_b-r != NULL)) {
style reads better, I dunno.
Is it 100% certain that the component counts are always 0 (or some known
value) for regex sections? Haven't peeked at the source to check that.
If not, an additional else {...} defending the component count comparison
when in regex sections might be safer.
Oh, well, enough C golf for today ;-).
- Barrie
Re: cvs commit: httpd-2.0/server core.c request.c
Quick_handler bypasses everything. We ignore the client's headers, the server's configuration, everything. Frankly, quick_handler is not Apache, and anyone who writes a quick_handler hack and calls it a module for 'Apache' is full of sh*t. Powered by the Apr/Apache MPM/load manager is more like it (that isn't badness, that's just reality.) That's a goofy way of looking at it. You might as well say that Redirect is not Apache because it ignores Directory sections. And let's not even get into what can be done by mod_rewrite. A quick_handler operates the way that a Web server is supposed to operate. I should be able to add a hook that detects a Code Red request and immediately close the connection with as little server overhead as possible. Normally I would do that with a custom change to the HTTP parser, but it makes more sense to do it as a hook with quick_handler. It isn't a security hole -- it is just another config directive. Roy
Re: cvs commit: httpd-2.0/server core.c request.c
From: Roy T. Fielding [EMAIL PROTECTED] Sent: Monday, August 27, 2001 4:45 PM A quick_handler operates the way that a Web server is supposed to operate. I should be able to add a hook that detects a Code Red request and immediately close the connection with as little server overhead as possible. Normally I would do that with a custom change to the HTTP parser, but it makes more sense to do it as a hook with quick_handler. I'd really like to see a quick_handler patch that has the socket drop that connection entirely, waiting in SYN for the ACK response :) Bill
Re: cvs commit: httpd-2.0/server core.c request.c
On Sat, Aug 25, 2001 at 11:43:19PM -, [EMAIL PROTECTED] wrote: wrowe 01/08/25 16:43:19 Modified:.CHANGES include http_request.h modules/http http_core.c http_protocol.c http_request.c mod_core.h server core.c request.c Log: Introduce the map_to_storage hook, which allows modules to bypass the directory_walk and file_walk for non-file requests. TRACE How is this different from the translate_name hook? Your new hook and the translate_name are both about translating URLs into the backend storage. Why was this new one added? (did I miss some discussion somewhere?) And if so, then why does translate_name stick around? Sounds similar to the quick_handler hook as well. Bill
Re: cvs commit: httpd-2.0/server core.c request.c
On Sat, Aug 25, 2001 at 11:43:19PM -, [EMAIL PROTECTED] wrote: wrowe 01/08/25 16:43:19 Modified:.CHANGES include http_request.h modules/http http_core.c http_protocol.c http_request.c mod_core.h server core.c request.c Log: Introduce the map_to_storage hook, which allows modules to bypass the directory_walk and file_walk for non-file requests. TRACE How is this different from the translate_name hook? Your new hook and the translate_name are both about translating URLs into the backend storage. Why was this new one added? (did I miss some discussion somewhere?) And if so, then why does translate_name stick around? I have the same question. Check out mod_jk and how it uses the translate_name hook. Bill
Re: cvs commit: httpd-2.0/server core.c request.c
From: Greg Stein [EMAIL PROTECTED] Sent: Sunday, August 26, 2001 4:04 AM On Sat, Aug 25, 2001 at 11:43:19PM -, [EMAIL PROTECTED] wrote: wrowe 01/08/25 16:43:19 Modified:.CHANGES include http_request.h modules/http http_core.c http_protocol.c http_request.c mod_core.h server core.c request.c Log: Introduce the map_to_storage hook, which allows modules to bypass the directory_walk and file_walk for non-file requests. TRACE How is this different from the translate_name hook? Your new hook and the translate_name are both about translating URLs into the backend storage. Why was this new one added? (did I miss some discussion somewhere?) And if so, then why does translate_name stick around? The original idea for the hook name was walkers (as in ap_run_walkers()). map_to_storage actually validates that the translated name is serveable, and sets up any storage specific per_dir_config values. It was also going to pick up the downgrade http protocol, but that doesn't make sense in this hook. I'll move that aspect to the bottom of the translate_name phase. Perhaps this should be get_storage_dir_config or something like that. Note it is run first, instead of run all (as the translate_name hook is), so that _one_ module can assume ownership and pick back up the request after the authz/authn phases. This hook has enormous reprecussions on avoiding directory walks and file walks that we have all complained so long about. The patches today to mod_proxy (adding a proxy_walk phase, and skipping the old cruft) illustrate this. Now that proxy and directory sections are listed seperately, we save a ton of tests in both given a complex server configuration. dir walks Dir sections, and proxy walks Proxy sections, period. The last remaining hurdle outside of dir/file walking is the duplicate Location walk we perform. I'm preparing a patch to do this walk once, and as long as the r-uri is unchanged, we continue to merge the same 'preconstructed' location walk every time we repeat that step. I want to lock down the default handler as well, to error 500 if we didn't call dir_walk/file_walk because a badly written module circumvented the core map_to_storage hook fn. After that, I believe we will be as good as can be, with some major cleanup needed to subreq/internal_internal_redirect handling. Bill
