Re: svn commit: r1639614 - /httpd/httpd/trunk/server/mpm/event/event.c
On Fri, Nov 14, 2014 at 1:04 PM, cove...@apache.org wrote:
Author: covener
Date: Fri Nov 14 12:04:46 2014
New Revision: 1639614
URL: http://svn.apache.org/r1639614
Log:
don't call notify_suspend() in a worker thread after
start_lingering_close_common may have put the socket back
into the pollset.
If it becomes readable too quickly, cs can be
free'ed or accessed concurrently.
Modified:
httpd/httpd/trunk/server/mpm/event/event.c
[]
+static int start_lingering_close_common(event_conn_state_t *cs, int
in_worker)
{
apr_status_t rv;
struct timeout_queue *q;
@@ -849,6 +861,9 @@ static int start_lingering_close_common(
cs-pub.sense == CONN_SENSE_WANT_WRITE ? APR_POLLOUT :
APR_POLLIN) | APR_POLLHUP | APR_POLLERR;
cs-pub.sense = CONN_SENSE_DEFAULT;
+if (in_worker) {
+notify_suspend(cs);
+}
Can't we put this outside the critical section?
(should the hook take non negligible time).
rv = apr_pollset_add(event_pollset, cs-pfd);
apr_thread_mutex_unlock(timeout_mutex);
if (rv != APR_SUCCESS !APR_STATUS_IS_EEXIST(rv)) {
Eg.
Index: server/mpm/event/event.c
===
--- server/mpm/event/event.c(revision 1642684)
+++ server/mpm/event/event.c(working copy)
@@ -859,16 +859,16 @@ static int start_lingering_close_common(event_conn
cs-pub.state = CONN_STATE_LINGER_NORMAL;
}
apr_atomic_inc32(lingering_count);
+cs-c-sbh = NULL;
+if (in_worker) {
+notify_suspend(cs);
+}
apr_thread_mutex_lock(timeout_mutex);
-cs-c-sbh = NULL;
TO_QUEUE_APPEND(*q, cs);
cs-pfd.reqevents = (
cs-pub.sense == CONN_SENSE_WANT_WRITE ? APR_POLLOUT :
APR_POLLIN) | APR_POLLHUP | APR_POLLERR;
cs-pub.sense = CONN_SENSE_DEFAULT;
-if (in_worker) {
-notify_suspend(cs);
-}
rv = apr_pollset_add(event_pollset, cs-pfd);
apr_thread_mutex_unlock(timeout_mutex);
if (rv != APR_SUCCESS !APR_STATUS_IS_EEXIST(rv)) {
--
Re: svn commit: r1639614 - /httpd/httpd/trunk/server/mpm/event/event.c
On Fri, Nov 14, 2014 at 1:04 PM, cove...@apache.org wrote:
Author: covener
Date: Fri Nov 14 12:04:46 2014
New Revision: 1639614
URL: http://svn.apache.org/r1639614
Log:
don't call notify_suspend() in a worker thread after
start_lingering_close_common may have put the socket back
into the pollset.
If it becomes readable too quickly, cs can be
free'ed or accessed concurrently.
Modified:
httpd/httpd/trunk/server/mpm/event/event.c
[]
@@ -1138,7 +1141,6 @@ read_request:
if (cs-pub.state == CONN_STATE_LINGER) {
start_lingering_close_blocking(cs);
-notify_suspend(cs);
}
Also, the old code notified unconditionally (too late, but always),
whereas now it will not should ap_start_lingering_close() fail in
start_lingering_close_blocking().
Shouldn't we :
Index: server/mpm/event/event.c
===
--- server/mpm/event/event.c(revision 1642684)
+++ server/mpm/event/event.c(working copy)
@@ -895,6 +895,8 @@ static int start_lingering_close_common(event_conn
static int start_lingering_close_blocking(event_conn_state_t *cs)
{
if (ap_start_lingering_close(cs-c)) {
+cs-c-sbh = NULL;
+notify_suspend(cs);
ap_push_pool(worker_queue_info, cs-p);
return 0;
}
return start_lingering_close_common(cs, 1);
}
?
Re: [RFC] CGIPassHeader Authorization|Proxy-Authorization|...
On Tue, Nov 25, 2014 at 8:39 PM, Eric Covener cove...@gmail.com wrote: On Tue, Nov 25, 2014 at 7:10 PM, Jeff Trawick traw...@gmail.com wrote: On Mon, Nov 24, 2014 at 12:16 PM, Eric Covener cove...@gmail.com wrote: On Thu, Aug 21, 2014 at 8:42 AM, Jeff Trawick traw...@gmail.com wrote: CGIPassHeader could be allowed in htaccess if the httpd admin has specified AllowOverride ... AuthConfig ...* or AllowOverrideList CGIPassHeader in the main config. Make sense? *Only auth headers are currently suppressed, so this directive could be named CGIPassAuthHeader and have a more visual tie to AuthConfig. +1 (a convo on IRC had me searching for this) http://people.apache.org/~trawick/cgipassheader.txt I didn't rename it to CGIPassAuthHeader, though that could/should be done. Maybe I forgot some unfinished piece since I wrote most of it weeks ago. It seems to work, however :) Any comments on the patch? looks good here Thanks for looking! A simpler version (CGIPassAuth On|Off) has been committed to trunk as r1642847. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: svn commit: r1639614 - /httpd/httpd/trunk/server/mpm/event/event.c
Index: server/mpm/event/event.c
===
--- server/mpm/event/event.c(revision 1642684)
+++ server/mpm/event/event.c(working copy)
@@ -859,16 +859,16 @@ static int start_lingering_close_common(event_conn
cs-pub.state = CONN_STATE_LINGER_NORMAL;
}
apr_atomic_inc32(lingering_count);
+cs-c-sbh = NULL;
+if (in_worker) {
+notify_suspend(cs);
+}
apr_thread_mutex_lock(timeout_mutex);
-cs-c-sbh = NULL;
TO_QUEUE_APPEND(*q, cs);
cs-pfd.reqevents = (
cs-pub.sense == CONN_SENSE_WANT_WRITE ? APR_POLLOUT :
APR_POLLIN) | APR_POLLHUP | APR_POLLERR;
cs-pub.sense = CONN_SENSE_DEFAULT;
-if (in_worker) {
-notify_suspend(cs);
-}
rv = apr_pollset_add(event_pollset, cs-pfd);
apr_thread_mutex_unlock(timeout_mutex);
if (rv != APR_SUCCESS !APR_STATUS_IS_EEXIST(rv)) {
+1
Re: ApacheCon Austin, httpd track
The idea is that being a project with a long, long history, httpd has the unfortunate reputation of being old, slow, and basically, not the new hotness. So even though the project has been around, 2.4 is vastly different, and really should be seen and considered as a whole new web server. On Nov 30, 2014, at 11:13 AM, Rich Bowen rbo...@rcbowen.com wrote: On Nov 29, 2014 9:45 AM, Jim Jagielski j...@jagunet.com wrote: I'd like to submit something like This ain't your Daddy's Apache!... Does that replace one of the ones already listed or is that a new item? On Nov 26, 2014, at 1:04 PM, Eric Covener cove...@gmail.com wrote: I've started an doc at https://docs.google.com/document/d/11oh1CQEwgxvV_xM92kQyRP8HuI92VHuN5znNz-5-Qwg/edit?usp=sharing and I'm hoping that we can collaborate on what talks need to be in a comprehensive httpd track, what order they should be in, and then hunt down the people that should be giving those talks. Thanks for kickstarting -- I added a very simple bullet for What’s (still new) in 2.4
Re: svn commit: r1639614 - /httpd/httpd/trunk/server/mpm/event/event.c
On Tue, Dec 2, 2014 at 5:52 AM, Yann Ylavic ylavic@gmail.com wrote:
Also, the old code notified unconditionally (too late, but always),
whereas now it will not should ap_start_lingering_close() fail in
start_lingering_close_blocking().
Shouldn't we :
Index: server/mpm/event/event.c
===
--- server/mpm/event/event.c(revision 1642684)
+++ server/mpm/event/event.c(working copy)
@@ -895,6 +895,8 @@ static int start_lingering_close_common(event_conn
static int start_lingering_close_blocking(event_conn_state_t *cs)
{
if (ap_start_lingering_close(cs-c)) {
+cs-c-sbh = NULL;
+notify_suspend(cs);
ap_push_pool(worker_queue_info, cs-p);
return 0;
}
return start_lingering_close_common(cs, 1);
}
+1
--
Eric Covener
cove...@gmail.com
Re: ApacheCon Austin, httpd track
I've updated the gdoc as proxying and load balancing On Dec 1, 2014, at 8:15 PM, Daniel Ruggeri drugg...@primary.net wrote: On 11/30/2014 11:08 AM, Jeff Trawick wrote: * deploying Python web apps under uWSGI behind mod_proxy_fcgi/scgi (some material here: http://emptyhammock.com/projects/info/pyweb/index.html) * a debugging tricks talk I've given a few times (relatively minor updates from the last North America AC) * drastically updated (rewritten) version of an old capacity-tuning-and-performance talk I gave at a Sun conference in 2009 (https://blogs.oracle.com/trawick/resource/DeepDive/WebStackDeepDiveApache.pdf) Similarly, I'm always up for giving my proxy talk if it's welcome (after the first day since I can't make it until Tues). If we think proxy is a big topic, we ought to arrange for a general overview like my proxy talk followed by more specific deep dives such as what Jeff mentions here and a session on new sexiness like WebSockets. Tuning for throughput is also an interesting topic and in line with the conversations lately (Re: commercial support). A side note on SSL/security: I had the idea a few years back that there is probably enough content to do a here is 5 minutes about how to configure SSL in httpd and then 50 minutes of other important security topics (What Ciphers should I enable? Should I use SSLv3 any more? How to treat my keys and what the hell is an HSM anyway? Passphrase encrypted keys or not? Should I trust my distro's build?). Thoughts are welcome on that topic... not sure if I'm overly paranoid or if these are things that people actually want to hear? -- Daniel Ruggeri
Re: Systemd support in 2.4
On Wed, Sep 17, 2014 at 9:22 AM, Jeff Trawick traw...@gmail.com wrote:
On Mon, Sep 15, 2014 at 2:00 AM, Jan Kaluža jkal...@redhat.com wrote:
On 09/14/2014 01:21 PM, Martynas Bendorius wrote:
Hello,
Is there any special reason why mod_systemd and mod_journald (available
in trunk) are not backported to 2.4 yet?
Hi,
I think mod_systemd could be proposed for 2.4 branch (maybe even with the
changes adding socket activation), but for mod_journald, we would have to
backport modular logging, which breaks the API/ABI and therefore I'm
afraid that won't happen in 2.4 branch :(.
I have an old patch somewhere that doesn't break the API/ABI, and
accommodates such differences as syslog being built-in in 2.4.x. I didn't
realize that anybody besides me actually cared.
I'll try to find time to see how it fits in 2.4.x-HEAD.
I've simply attached it from its state one year ago, not having time to
play with it. I don't think it is necessary to break the ABI. syslog
support remains part of core logging instead of in a module.
Jan Kaluza
As we have a lot of distributions already using systemd by default
(CentOS/RHEL 7, Fedora, Arch Linux, CoreOS, openSUSE), and more of them
are going to use systemd by default (Debian 8 (Jessie), Ubuntu), it
requires manual patching of apache for the support of systemd/journald.
Thank you!
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Index: docs/manual/mod/core.xml
===
--- docs/manual/mod/core.xml(revision 1545470)
+++ docs/manual/mod/core.xml(working copy)
@@ -1293,10 +1293,10 @@
more information./p
pUsing codesyslog/code instead of a filename enables logging
-via syslogd(8) if the system supports it. The default is to use
-syslog facility codelocal7/code, but you can override this by
-using the codesyslog:varfacility/var/code syntax where
-varfacility/var can be one of the names usually documented in
+via syslogd(8) if the system supports it and if modulemod_syslog/module
+is loaded. The default is to use syslog facility codelocal7/code,
+but you can override this by using the
codesyslog:varfacility/var/code
+syntax where varfacility/var can be one of the names usually
documented in
syslog(1). The facility is effectively global, and if it is changed
in individual virtual hosts, the final facility specified affects the
entire server./p
@@ -1303,6 +1303,9 @@
highlight language=configErrorLog syslog:user/highlight
+pAdditional modules can provide their own ErrorLog providers. The syntax
+is similar to codesyslog/code example above./p
+
pSECURITY: See the a
href=../misc/security_tips.html#serverrootsecurity tips/a
document for details on why your security could be compromised
Index: docs/manual/mod
===
--- docs/manual/mod (revision 1545470)
+++ docs/manual/mod (working copy)
Property changes on: docs/manual/mod
___
Modified: svn:mergeinfo
Merged /httpd/httpd/trunk/docs/manual/mod:r1525597
Index: docs/manual
===
--- docs/manual (revision 1545470)
+++ docs/manual (working copy)
Property changes on: docs/manual
___
Modified: svn:mergeinfo
Merged /httpd/httpd/trunk/docs/manual:r1525597
Index: include/http_core.h
===
--- include/http_core.h (revision 1545470)
+++ include/http_core.h (working copy)
@@ -826,8 +826,55 @@
/** message format */
const char *format;
+
+/** 1 if logging using provider, 0 otherwise */
+int using_provider;
} ap_errorlog_info;
+#define AP_ERRORLOG_PROVIDER_GROUP error_log_writer
+#define AP_ERRORLOG_PROVIDER_VERSION 0
+#define AP_ERRORLOG_DEFAULT_PROVIDER file
+
+/** add APR_EOL_STR to the end of log message */
+#define AP_ERRORLOG_PROVIDER_ADD_EOL_STR 1
+
+typedef struct ap_errorlog_provider ap_errorlog_provider;
+
+struct ap_errorlog_provider {
+/** Initializes the error log writer.
+ * @param p The pool to create any storage from
+ * @param s Server for which the logger is initialized
+ * @return Pointer to handle passed later to writer() function
+ * @note On success, the provider must return non-NULL, even if
+ * the handle is not necessary when the writer() function is
+ * called. On failure, the provider should log a startup error
+ * message and return NULL to abort httpd startup.
+ */
+void * (*init)(apr_pool_t *p, server_rec *s);
+
+/** Logs the error message to external error log.
+ * @param info Context of the error message
+ * @param handle Handle created by init() function
+ * @param errstr Error message
+ *
svn:mergeinfo from docs/manual/rewrite/advanced.xml
Hi, it seems that anytime I try to merge something from trunk into my working 2.4.x, it produces a mergeinfo for docs/manual/rewrite/advanced.xml. What's mergeinfo policy in httpd? Is that expected? Regards, Yann.
Re: ApacheCon Austin, httpd track
On 12/01/2014 08:15 PM, Daniel Ruggeri wrote: A side note on SSL/security: I had the idea a few years back that there is probably enough content to do a here is 5 minutes about how to configure SSL in httpd and then 50 minutes of other important security topics (What Ciphers should I enable? Should I use SSLv3 any more? How to treat my keys and what the hell is an HSM anyway? Passphrase encrypted keys or not? Should I trust my distro's build?). Thoughts are welcome on that topic... not sure if I'm overly paranoid or if these are things that people actually want to hear? Given the focus on SSL in the last year, I think that a talk exactly like that would be appreciated, and could even be a great talk to use to market the track as a whole. I think a lot of people are waking up to the fact that they have no idea what SSL/TLS actually is, and some in-depth teaching on it seems like it would be welcome. --Rich -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon
Re: svn:mergeinfo from docs/manual/rewrite/advanced.xml
On Tue, Dec 2, 2014 at 8:57 AM, Yann Ylavic ylavic@gmail.com wrote: Hi, it seems that anytime I try to merge something from trunk into my working 2.4.x, it produces a mergeinfo for docs/manual/rewrite/advanced.xml. What's mergeinfo policy in httpd? Is that expected? I am probably guilty of not doing merges correctly, causing mergeinfo to be omitted. I think Greg had guided us to always merge into a clean tree and commit . But there did seem to be a huge influx of mergeinfo from rbowens r1622292 including the one giving you a problem. I can't imagine that specific instance of the data is serving any purpose
Re: svn:mergeinfo from docs/manual/rewrite/advanced.xml
On 12/02/2014 09:56 AM, Eric Covener wrote: On Tue, Dec 2, 2014 at 8:57 AM, Yann Ylavic ylavic@gmail.com wrote: Hi, it seems that anytime I try to merge something from trunk into my working 2.4.x, it produces a mergeinfo for docs/manual/rewrite/advanced.xml. What's mergeinfo policy in httpd? Is that expected? I am probably guilty of not doing merges correctly, causing mergeinfo to be omitted. I think Greg had guided us to always merge into a clean tree and commit . But there did seem to be a huge influx of mergeinfo from rbowens r1622292 including the one giving you a problem. I can't imagine that specific instance of the data is serving any purpose Sorry about that. Not sure what I did there. :( -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon
Re: svn commit: r1545408 - in /httpd/httpd/trunk/server/mpm: event/fdqueue.c eventopt/fdqueue.c
Hi,
yes, it's been a while now, sorry for that...
On Mon, Nov 25, 2013 at 10:10 PM, j...@apache.org wrote:
Author: jim
Date: Mon Nov 25 21:10:05 2013
New Revision: 1545408
URL: http://svn.apache.org/r1545408
Log:
naming suggestion re: trawick
Modified:
httpd/httpd/trunk/server/mpm/event/fdqueue.c
[]
--- httpd/httpd/trunk/server/mpm/event/fdqueue.c (original)
+++ httpd/httpd/trunk/server/mpm/event/fdqueue.c Mon Nov 25 21:10:05 2013
@@ -127,9 +127,9 @@
apr_status_t ap_queue_info_try_get_idler(fd_queue_info_t * queue_info)
{
-int prev_idlers;
-prev_idlers = apr_atomic_add32((apr_uint32_t *)(queue_info-idlers),
-1) - zero_pt;
-if (prev_idlers = 0) {
+int new_idlers;
+new_idlers = apr_atomic_add32((apr_uint32_t *)(queue_info-idlers), -1)
- zero_pt;
+if (--new_idlers = 0) {
apr_atomic_inc32((apr_uint32_t *)(queue_info-idlers));/* back
out dec */
return APR_EAGAIN;
}
This change is a follow up to http://svn.apache.org/r1545286, based on
the original code (more than 3 years old, by sf@) :
@@ -131,7 +128,7 @@
apr_status_t ap_queue_info_try_get_idler(fd_queue_info_t * queue_info)
{
int prev_idlers;
-prev_idlers = apr_atomic_dec32((apr_uint32_t *)(queue_info-idlers));
+prev_idlers = apr_atomic_add32((apr_uint32_t
*)(queue_info-idlers), -1) - zero_pt;
if (prev_idlers = 0) {
apr_atomic_inc32((apr_uint32_t *)(queue_info-idlers));
/* back out dec */
return APR_EAGAIN;
The whole is consistent with the original code, since
apr_atomic_dec32() returned the new value (sub-and-fecth), whereas
apr_atomic_add32() now returns the previous value (fetch-and-sub),
thus --new_idlers in the new code is equal to prev_idlers in the
original code, so r1545286 + r1545408 did not change the semantic of
ap_queue_info_try_get_idler().
However I think this semantic was/is incorrect.
Let's look at the current (full) code :
apr_status_t ap_queue_info_try_get_idler(fd_queue_info_t * queue_info)
{
apr_int32_t new_idlers;
a. new_idlers = apr_atomic_add32((queue_info-idlers), -1) - zero_pt;
b. if (--new_idlers = 0) {
apr_atomic_inc32((queue_info-idlers));/* back out dec */
return APR_EAGAIN;
}
return APR_SUCCESS;
}
Suppose there is initially one idle woker (ie. queue_info-idlers is
1), no concurrency.
After a. new_idlers is 1, and after b. it is 0 = EAGAIN.
Shouldn't ap_queue_info_try_get_idler() consume the last idler in this case?
I think the code should really be (back to r1545286) :
apr_status_t ap_queue_info_try_get_idler(fd_queue_info_t * queue_info)
{
apr_int32_t prev_idlers;
prev_idlers = apr_atomic_add32((queue_info-idlers), -1) - zero_pt;
if (prev_idlers = 0) {
apr_atomic_inc32((queue_info-idlers));/* back out dec */
return APR_EAGAIN;
}
return APR_SUCCESS;
}
or even :
apr_status_t ap_queue_info_try_get_idler(fd_queue_info_t * queue_info)
{
for (;;) {
apr_uint32_t prev_idlers;
apr_uint32_t loop_idlers = queue_info-idlers;
prev_idlers = apr_atomic_cas32(queue_info-idlers,
loop_idlers - (loop_idlers ZERO_PT),
loop_idlers);
if (prev_idlers = ZERO_PT) {
return APR_EAGAIN;
}
if (prev_idlers == loop_idlers) {
return APR_SUCCESS;
}
}
}
so that we don't need to back out dec when there is no idler (thus
avoiding a race with the other threads in the time between dec32 and
inc32).
Am I missing something?
Regards,
Yann.
RE: Re: ApacheCon Austin, httpd track
- Original Message - Subject: Re: ApacheCon Austin, httpd track From: Rich Bowen rbo...@rcbowen.com Date: 12/2/14 8:29 am To: dev@httpd.apache.org On 12/01/2014 08:15 PM, Daniel Ruggeri wrote: A side note on SSL/security: I had the idea a few years back that there is probably enough content to do a here is 5 minutes about how to configure SSL in httpd and then 50 minutes of other important security topics (What Ciphers should I enable? Should I use SSLv3 any more? How to treat my keys and what the hell is an HSM anyway? Passphrase encrypted keys or not? Should I trust my distro's build?). Thoughts are welcome on that topic... not sure if I'm overly paranoid or if these are things that people actually want to hear? Given the focus on SSL in the last year, I think that a talk exactly like that would be appreciated, and could even be a great talk to use to market the track as a whole. I think a lot of people are waking up to the fact that they have no idea what SSL/TLS actually is, and some in-depth teaching on it seems like it would be welcome. Rich raises a great point - you could probably even propose a full half day training, and spend a bit of time on configuring different ASF projects (e.g. httpd, Tomcat) while aiming squarely at the state of SSL cryptography itself. I'm certain that class would get some nice registration numbers.
Re: svn commit: r1642154 - in /httpd/httpd/trunk: docs/manual/expr.xml include/ap_expr.h server/util_expr_eval.c server/util_expr_parse.y
On 11/27/2014 02:46 PM, jkal...@apache.org wrote:
Author: jkaluza
Date: Thu Nov 27 13:46:11 2014
New Revision: 1642154
URL: http://svn.apache.org/r1642154
Log:
* ap_exr: Add replace(string, from, to) function.
Modified:
httpd/httpd/trunk/docs/manual/expr.xml
httpd/httpd/trunk/include/ap_expr.h
httpd/httpd/trunk/server/util_expr_eval.c
httpd/httpd/trunk/server/util_expr_parse.y
Modified: httpd/httpd/trunk/server/util_expr_eval.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_expr_eval.c?rev=1642154r1=1642153r2=1642154view=diff
==
--- httpd/httpd/trunk/server/util_expr_eval.c (original)
+++ httpd/httpd/trunk/server/util_expr_eval.c Thu Nov 27 13:46:11 2014
@@ -183,13 +186,29 @@ static const char *ap_expr_eval_string_f
const ap_expr_t *info,
const ap_expr_t *arg)
{
-ap_expr_string_func_t *func = (ap_expr_string_func_t *)info-node_arg1;
const void *data = info-node_arg2;
AP_DEBUG_ASSERT(info-node_op == op_StringFuncInfo);
-AP_DEBUG_ASSERT(func != NULL);
+AP_DEBUG_ASSERT(info-node_arg1 != NULL);
AP_DEBUG_ASSERT(data != NULL);
-return (*func)(ctx, data, ap_expr_eval_word(ctx, arg));
+if (arg-node_op == op_ListElement) {
+/* Evaluate the list elements and store them in apr_array_header. */
+ap_expr_string_list_func_t *func = (ap_expr_string_list_func_t
*)info-node_arg1;
+apr_array_header_t *args = apr_array_make(ctx-p, 1, sizeof(char *));
Shouldn't we use at least 2 instead of 1? I guess we expect at least 2 elements.
+do {
+const ap_expr_t *val = arg-node_arg1;
+const char **new = apr_array_push(args);
+*new = ap_expr_eval_word(ctx, val);
+
+arg = arg-node_arg2;
+} while (arg != NULL);
+
+return (*func)(ctx, data, args);
+}
+else {
+ap_expr_string_func_t *func = (ap_expr_string_func_t
*)info-node_arg1;
+return (*func)(ctx, data, ap_expr_eval_word(ctx, arg));
+}
}
static int intstrcmp(const char *s1, const char *s2)
@@ -1071,6 +1110,59 @@ static const char *ldap_func(ap_expr_eva
}
#endif
+static int replace_func_parse_arg(ap_expr_lookup_parms *parms)
+{
+const char *original = parms-arg;
+const apr_strmatch_pattern *pattern;
+
+if (!parms-arg) {
+*parms-err = apr_psprintf(parms-ptemp, replace() function needs
+ exactly 3 arguments);
+return !OK;
+}
+pattern = apr_strmatch_precompile(parms-pool, original, 0);
+*parms-data = pattern;
+return OK;
+}
+
+static const char *replace_func(ap_expr_eval_ctx_t *ctx, const void *data,
+ const apr_array_header_t *args)
+{
+char *buff, *original, *replacement;
+struct ap_varbuf vb;
+apr_size_t repl_len;
+const char *repl;
+apr_size_t bytes;
+apr_size_t len;
+const apr_strmatch_pattern *pattern = data;
+if (args-nelts != 3) {
+*ctx-err = apr_psprintf(ctx-p, replace() function needs
+ exactly 3 arguments);
+return ;
+}
+
+buff = APR_ARRAY_IDX(args, 2, char *);
+original = APR_ARRAY_IDX(args, 1, char *);
+replacement = APR_ARRAY_IDX(args, 0, char *);
+repl_len = strlen(replacement);
+bytes = strlen(buff);
+
+ap_varbuf_init(ctx-p, vb, 0);
+vb.strlen = 0;
+
+while ((repl = apr_strmatch(pattern, buff, bytes))) {
+len = (apr_size_t) (repl - buff);
+ap_varbuf_strmemcat(vb, buff, len);
+ap_varbuf_strmemcat(vb, replacement, repl_len);
+
+len += repl_len;
This goes wrong if replacement string and original string are of different
size. IMHO you need to add strlen(original)
to len above.
+bytes -= len;
+buff += len;
+}
+
+return ap_varbuf_pdup(ctx-p, vb, NULL, 0, buff, bytes, len);
+}
+
#define MAX_FILE_SIZE 10*1024*1024
static const char *file_func(ap_expr_eval_ctx_t *ctx, const void *data,
char *arg)
@@ -1657,6 +1749,7 @@ static const struct expr_provider_single
Regards
Rüdiger
Re: ApacheCon Austin, httpd track
On 11/30/2014 11:08 AM, Jeff Trawick wrote: * deploying Python web apps under uWSGI behind mod_proxy_fcgi/scgi (some material here: http://emptyhammock.com/projects/info/pyweb/index.html) On 1 Dec 2014, at 19:15, Daniel Ruggeri drugg...@primary.net wrote: Similarly, I'm always up for giving my proxy talk if it's welcome (after the first day since I can't make it until Tues). If we think proxy is a big topic, we ought to arrange for a general overview like my proxy talk followed by more specific deep dives such as what Jeff mentions here and a session on new sexiness like WebSockets. Picking up on what Jeff and Daniel are saying, I think some focus on the powerful things mod_proxy_* can do would be really useful. One particular thought that has been in the back of my head for some time is a Begone libphp5.so! talk. For better or worse, PHP is still around and will be for some time, but it is time to get it out of the web server and treat it like the application/backend it is for both security and resource-usage reasons. mod_proxy_fcgi + php-fpm is a really elegant, simple solution to make this happen, but I have found a lot of devs and admins who just aren't even aware of this configuration possibility. (I have explained it to several people at ApacheCon NAs over the past couple of years.) I've actually been using a backported mod_proxy_fcgi in 2.2 for just this purpose for a few years in production. That's certainly a talk I would be willing to give if there is interest. P.S. mod_proxy_balancer - mod_proxy_fcgi - php-fpm is really fun and interesting too! ;-)
Re: svn commit: r1642851 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/scoreboard.c
Hi,
should the same logic be applied in:
- ap_increment_counts (at line 367) ? (code looks like in
ap_time_process_request where the 0 test is done)
CJ
Le 02/12/2014 13:42, j...@apache.org a écrit :
Author: jim
Date: Tue Dec 2 12:42:39 2014
New Revision: 1642851
URL: http://svn.apache.org/r1642851
Log:
Merge r1638073 from trunk:
* server/scoreboard.c: Check for child_num 0 also in ap_update_child_status
and ap_update_child_status_from_conn. PR 56767.
Submitted by: jkaluza
Reviewed/backported by: jim
Modified:
httpd/httpd/branches/2.4.x/ (props changed)
httpd/httpd/branches/2.4.x/STATUS
httpd/httpd/branches/2.4.x/server/scoreboard.c
Propchange: httpd/httpd/branches/2.4.x/
--
Merged /httpd/httpd/trunk:r1638073
Modified: httpd/httpd/branches/2.4.x/STATUS
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1642851r1=1642850r2=1642851view=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Tue Dec 2 12:42:39 2014
@@ -104,12 +104,6 @@ RELEASE SHOWSTOPPERS:
PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
- * core: Check for child_num 0 also in ap_update_child_status
- and ap_update_child_status_from_conn in scoreboard.c. PR 56767.
- trunk patch: http://svn.apache.org/r1638073
- 2.4.x patch: trunk works
- +1: jkaluza, covener, ylavic
-
* core: Do not match files when using DirectoryMatch. PR 41867.
trunk patch: http://svn.apache.org/r1635428
2.4.x patch:
http://people.apache.org/~jkaluza/patches/httpd-2.4.x-directorymatch.patch
Modified: httpd/httpd/branches/2.4.x/server/scoreboard.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/server/scoreboard.c?rev=1642851r1=1642850r2=1642851view=diff
==
--- httpd/httpd/branches/2.4.x/server/scoreboard.c (original)
+++ httpd/httpd/branches/2.4.x/server/scoreboard.c Tue Dec 2 12:42:39 2014
@@ -527,7 +527,7 @@ AP_DECLARE(int) ap_update_child_status_f
AP_DECLARE(int) ap_update_child_status(ap_sb_handle_t *sbh, int status,
request_rec *r)
{
-if (!sbh)
+if (!sbh || (sbh-child_num 0))
return -1;
return update_child_status_internal(sbh-child_num, sbh-thread_num,
@@ -539,7 +539,7 @@ AP_DECLARE(int) ap_update_child_status(a
AP_DECLARE(int) ap_update_child_status_from_conn(ap_sb_handle_t *sbh, int
status,
conn_rec *c)
{
-if (!sbh)
+if (!sbh || (sbh-child_num 0))
return -1;
return update_child_status_internal(sbh-child_num, sbh-thread_num,
