svn commit: r161661 - incubator/httpd/cli
Author: noel Date: Sun Apr 17 08:02:38 2005 New Revision: 161661 URL: http://svn.apache.org/viewcvs?view=revrev=161661 Log: remove remnants of CLI. contents already moved to httpd project Removed: incubator/httpd/cli/
Re: prefix_stat() problems in mod_rewrite?
* Chris Darroch [EMAIL PROTECTED] wrote: What I noticed was that prefix_stat() seems to implement a heuristic that attempts to decide whether or not the URI has been mapped out of the document root, because if it hasn't, then the document root needs to be prepended to the URI and written into r-filename. Yes. My inclination would be -- although I realize this might cause painful problems for admins upgrading Apache -- to eliminate this source of confusion and potential mischief by removing prefix_stat() and the logic around it, and instead always prepending the document root in hook_uri2file(), unless a specific rule configuration flag was used, maybe A for alias? (This would be unrelated to the passthrough mode, where hook_uri2file() munges r-uri and then returns DECLINED; this would relate to the normal case of returning OK to end the translate_name phase.) I've had the same idea for some time, but never got some time to spare. However: - It's for 2.1 and later. I wouldn't touch the stable branches; further mod_rewrite in 2.1 should be easier to edit, because it was refactored a bit. - I'd make it configurable (but defaulting to the new variant); i.e. some option for RewriteOptions - The same thing applies for automatic userdir resolution, I'd introduce an 'U' flag or the like. This obviously means a fair bit of coding work, especially since I'm not sure what it would entail in relation to rewrites done in a per-directory context -- maybe nothing? Yep, dir context is not affected. Thoughts, comments, criticisms, errors in the above? Comment: You're describing the darkest one of the black mod_rewrite magic. ;-) nd
what tool can detect memory leak in mod?
Hi all I have developed a mod in apache . When a http request came, my mod can do some work and release sources it created. It seam work fine except when run it a long time . I ever used valgrind (a memory leak tool), but it is not good for using in apache mod . Does any one know a memory leak tool can use in apache mod developing ? THanks! Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides!
RFC 3870 / mimetype for RDF / Semantic Web
Any objections to me adding the RDF mimetype: application/rdf+xml rdf to mime.types; see http://www.faqs.org/rfcs/rfc3870.html for the formal registration. Essentially as more and more blog's and what not are producing these; and sending them out as our default text/plain. Dw.
Re: RFC 3870 / mimetype for RDF / Semantic Web
On Mon, 18 Apr 2005, Dirk-Willem van Gulik wrote: Any objections to me adding the RDF mimetype: application/rdf+xml rdf Apologies - ignore this; it was already added 2 years ago: +++ mime.types 2003/07/10 14:56:02 1.39 Dw. (Who needs to learn that rdf is not spelled as rfd when grepping).
Re: simple-conf branch
Greg Stein wrote: On Mon, Apr 04, 2005 at 01:03:27PM -0500, William A. Rowe, Jr. wrote: At 09:37 AM 4/4/2005, Brad Nicholes wrote: +1 to Greg's comment, I also think that for a new users, having a bunch of little .conf files will be more confusing. For experienced users, they will split up the .conf file however they see fit anyway. So it doesn't really matter. With all due respect, if we break this into 'logical' groups, I believe it will make it easier for the new user to learn each group of features, one .conf fragment at a time. Most 'cookbooks' are organized this way, and it turns out to be a great method of teaching. Sorry, but I very much disagree. I think back to the old days of access.conf, httpd.conf, and srm.conf. As an administrator, I absolutely detested that layout. I could NEVER figure out which file a given configuration was in. I always had to search, then edit. We've been to the multiple .conf world before. It sucked. We pulled everything back into a single .conf to get the hell outta there. Small examples are fine. The default configuration should remain as a single .conf file. Which should be almost entirely empty. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
[PATCH] mod_ssl: merge ssl_hook_Translate into ssl_hook_ReadReq
Is there any good reason why the ssl_hook_Translate functionality really
has to be in a translate_name hook? PR 34452 is a nice snafu where the
ssl-unclean-shutdown setting is not taking effect if using a reverse
proxy, because the mod_ssl translate_hook never gets run. mod_proxy is
only one common module which will trigger this, of course...
(this is a regression since 2.0.49 where mod_ssl started doing proper
SSL shutdowns, but it looks like it would affect 1.3+mod_ssl 2.8 too)
Moving this code to the post_read_request hook seems like a clean
solution; making sure the hook runs after mod_setenvif's match_headers.
Am I missing anything?
Index: modules/ssl/ssl_private.h
===
--- modules/ssl/ssl_private.h (revision 161430)
+++ modules/ssl/ssl_private.h (working copy)
@@ -531,7 +531,6 @@
apr_status_t ssl_init_ModuleKill(void *data);
/* Apache API hooks */
-int ssl_hook_Translate(request_rec *);
int ssl_hook_Auth(request_rec *);
int ssl_hook_UserCheck(request_rec *);
int ssl_hook_Access(request_rec *);
Index: modules/ssl/ssl_engine_kernel.c
===
--- modules/ssl/ssl_engine_kernel.c (revision 161430)
+++ modules/ssl/ssl_engine_kernel.c (working copy)
@@ -30,6 +30,8 @@
-- Unknown*/
#include ssl_private.h
+static void ssl_configure_env(request_rec *r, SSLConnRec *sslconn);
+
/*
* Post Read Request Handler
*/
@@ -84,7 +86,31 @@
if ((ssl = sslconn-ssl)) {
SSL_set_app_data2(ssl, r);
}
+else {
+return DECLINED;
+}
+/*
+ * Log information about incoming HTTPS requests
+ */
+if (r-server-loglevel = APLOG_INFO ap_is_initial_req(r)) {
+ap_log_error(APLOG_MARK, APLOG_INFO, 0, r-server,
+ %s HTTPS request received for child %ld (server %s),
+ (r-connection-keepalives = 0 ?
+ Initial (No.1) :
+ apr_psprintf(r-pool, Subsequent (No.%d),
+ r-connection-keepalives+1)),
+ r-connection-id,
+ ssl_util_vhostid(r-pool, r-server));
+}
+
+/* SetEnvIf ssl-*-shutdown flags can only be per-server,
+ * so they won't change across keepalive requests
+ */
+if (sslconn-shutdown_type == SSL_SHUTDOWN_TYPE_UNSET) {
+ssl_configure_env(r, sslconn);
+}
+
return DECLINED;
}
@@ -126,41 +152,6 @@
}
/*
- * URL Translation Handler
- */
-int ssl_hook_Translate(request_rec *r)
-{
-SSLConnRec *sslconn = myConnConfig(r-connection);
-
-if (!(sslconn sslconn-ssl)) {
-return DECLINED;
-}
-
-/*
- * Log information about incoming HTTPS requests
- */
-if (r-server-loglevel = APLOG_INFO ap_is_initial_req(r)) {
-ap_log_error(APLOG_MARK, APLOG_INFO, 0, r-server,
- %s HTTPS request received for child %ld (server %s),
- (r-connection-keepalives = 0 ?
- Initial (No.1) :
- apr_psprintf(r-pool, Subsequent (No.%d),
- r-connection-keepalives+1)),
- r-connection-id,
- ssl_util_vhostid(r-pool, r-server));
-}
-
-/* SetEnvIf ssl-*-shutdown flags can only be per-server,
- * so they won't change across keepalive requests
- */
-if (sslconn-shutdown_type == SSL_SHUTDOWN_TYPE_UNSET) {
-ssl_configure_env(r, sslconn);
-}
-
-return DECLINED;
-}
-
-/*
* Access Handler
*/
int ssl_hook_Access(request_rec *r)
Index: modules/ssl/mod_ssl.c
===
--- modules/ssl/mod_ssl.c (revision 161430)
+++ modules/ssl/mod_ssl.c (working copy)
@@ -478,6 +478,10 @@
static void ssl_register_hooks(apr_pool_t *p)
{
+/* ssl_hook_ReadReq needs to use the BrowserMatch settings so must
+ * run after mod_setenvif's post_read_request hook. */
+static const char *pre_prr[] = { mod_setenvif.c, NULL };
+
ssl_io_filter_register(p);
ap_hook_pre_connection(ssl_hook_pre_connection,NULL,NULL, APR_HOOK_MIDDLE);
@@ -487,12 +491,11 @@
ap_hook_default_port (ssl_hook_default_port, NULL,NULL, APR_HOOK_MIDDLE);
ap_hook_pre_config(ssl_hook_pre_config,NULL,NULL, APR_HOOK_MIDDLE);
ap_hook_child_init(ssl_init_Child, NULL,NULL, APR_HOOK_MIDDLE);
-ap_hook_translate_name(ssl_hook_Translate, NULL,NULL, APR_HOOK_MIDDLE);
ap_hook_check_user_id (ssl_hook_UserCheck, NULL,NULL, APR_HOOK_FIRST);
ap_hook_fixups(ssl_hook_Fixup, NULL,NULL, APR_HOOK_MIDDLE);
ap_hook_access_checker(ssl_hook_Access,NULL,NULL, APR_HOOK_MIDDLE);
ap_hook_auth_checker (ssl_hook_Auth, NULL,NULL, APR_HOOK_MIDDLE);
-
Re: AP_MODE_EATCRLF considered indigestible
Justin Erenkrantz wrote: On Fri, Apr 15, 2005 at 03:46:37PM -0400, Greg Ames wrote: it is sounding better all the time as far as performance. if I understand you correctly I think this one eliminates the extra trips down the input and output filter chains. but unfortunately we still have the extra read() compared to 1.3, and what about data stashed in the input filter chain? Well, I think the extra read() is required if we want to see if there is a pending request in the pipeline (heh). I wouldn't see a way to know that without that read() [...] I'm guessing 1.3 just didn't even bother doing a read() on the socket...which sort ofbegs the question, why are we doing that in 2.x then? the people who put the code into 1.3 realized that the whole thing is an optimization, therefore you loose if you spend too many cycles on it. if the network data for pipelined request n+1 isn't already present during ap_read_request for request n, it is highly unlikely to arrive by the time we start writing the response for request n. if a new request does arrive during that window it's no big deal. we might write one small packet to the network and nothing breaks. why are we doing the read() in 2.x? I believe it was a lack of deep understanding of how 1.3 works and a rush to get something working with input filters. but now it's time to move beyond the proof of concept. But, moving it to a request output filter triggered by EOS presence does eliminate one round trip through the filter chain which can save CPU cycles. So, I guess what we should do is let Rici finish up the patch to implement EATCRLF entirely via speculative reads - ensure that works and then we can move around that code as necessary. let's eliminate the speculative read too. that's a round trip down the input filter chain we don't need. all we need to know is if there is data stashed in the input filters. the input filters can indicate that somehow every time they are called and save a lot of cycles. Greg
Re: AP_MODE_EATCRLF considered indigestible
On 18-Apr-05, at 9:43 AM, Greg Ames wrote: if the network data for pipelined request n+1 isn't already present during ap_read_request for request n, it is highly unlikely to arrive by the time we start writing the response for request n. It may well arrive during the time we're writing the response, though, if it is based on information from the response. if a new request does arrive during that window it's no big deal. we might write one small packet to the network and nothing breaks. I agree with this. I doubt whether the optimization actually buys enough to make it worth the trouble. Also, if we ever get it wrong and leave unflushed data at the end of a request, it will look like the request is stalled.
Re: svn commit: r159941 - httpd/httpd/branches/simple-conf/Makefile.in
Rici Lake wrote: This didn't quite get it right, either. It will overwrite the .conf file unless the .conf file is httpd.conf (rather than progname.conf) Thanks. Committed. Joshua.
