Re: Question on sub requests and output filter context.
On Thu, Sep 15, 2011 at 12:52, Martin Townsend martin.towns...@power-oasis.com wrote: Hi, I have an output filter that parses custom tags to retrieve data from an application running on the same device. Everything was working well until I tried to move some HTML into Server Side Include pages. Snippet below: ?smu smu extio_sensor_read mappings ? ?smu smu extio_read front_ana all led ? ?smu smu extio_read rear_ana all led ? !--#include virtual=/include/SSI_SensorStatus.html -- !--#include virtual=/include/SSI_SensorStatusAnalogRear.html -- The first three commands will populate hash tables that are saved in my output filters context. The HTML in the included pages then use custom tags to query the hash tables but for some reason the hash tables are NULL. Having stepped through with the debugger I can see that the pointer to the output filter when processing the main HTML page is different to the one when parsing custom tags in SSI pages. Looking through mod_include I can see it creates a sub request for include and sub requests call make_sub_request to create a new filter. Should this new filter also inherit the output filters context? Am I doing something wrong with my use of mod_include? I've tried moving my filter so it's after mod_include but still the same problem. I'm using Server version: Apache/2.2.19 (Unix) on an ARM board. Best Regards, Martin. How do you construct the context of your filter? At the first invokation of the filter or in the init function of the filter? In the second case, it could be that you construct the context twice, the first time in the main request processing and the second time in the subrequest processing. In my opinion, apache uses the same filter structure in both the main and the sub request. In mod_includes apache creates a subrequest, passing f-next to it. Thus, the first filter in the filter chain of the subrequest is the filter succeeding the INCLUDES filter. In my opinion, if you place your filter before the INCLUDES filter, your filter should not be called in the subrequest if yours is a AP_FTYPE_RESOURCE filter. If you place your filter after the INCLUDES filter, the hash tables you mention are not initialised at the time when your filter processes the responses of the includes subrequests. I am not sure of what I'm saying because I have no experience in how mod_includes interacts with other filters. Anyway, I hope this helps. Have a look in server/request.c at make_sub_request. The subrequest inherits the protocol filters of the main request, but not all of the non-protocol output filters of the main request. Maybe you should make your filter a AP_FTYPE_PROTOCOL filter such that it is not removed from the chain by mod_includes. S
Re: Question on sub requests and output filter context.
On Thu, 2011-09-15 at 11:52 +0100, Martin Townsend wrote: Having stepped through with the debugger I can see that the pointer to the output filter when processing the main HTML page is different to the one when parsing custom tags in SSI pages. This is IMHO expected behavior. Different requests have different filter records. Sincerely, Joachim
Re: Documentation clarification: ErrorLogFormat
On Sunday 18 September 2011, Rich Bowen wrote: On Sep 17, 2011, at 10:56 PM, Rich Bowen wrote: In the documentation for the ErrorLogFormat directive, log format strings are given as, for example, %...A What does the ... signify? It's not clear to me either from the doc (which doesn't mention it) or the source what that's supposed to signify. My apologies. It *is* mentioned in the documentation. It's where the modifier (-, +, or a number 1-15 signifying the log level) goes. I'll add some examples in there so that people, like myself, who can't read, don't overlook it. :) If you think the ... are confusing, feel free to remove them. Or add an explanation sentence to the table. The default format example has some modifiers. Maybe it should be moved before the paragraph describing the modifiers?
Re: Bug report for Apache httpd-2 [2011/09/18]
On Sunday 18 September 2011, bugzi...@apache.org wrote: |cause mod_aut| 22005|Ver|Nor|2003-07-30|Win32: Help I'm Stuck! menu item leads to dead e| Ver == status verified, which means the reporter has verified that a resolved bug is actually fixed. Can we omit PRs with that status from the summary mail? Thanks.
Re: Pushing for httpd 2.4.0 GA
I think the windows accept filter issue is a real blocker. The only alternative would be to release 2.4.0 without official support for Windows. I took a look at this in the AM, and it looks like the acceptfilter none path is relying on data set only by AcceptEX (context-buffer) to fill in context-sa_server (child.c:590). In 2.2 the context-buffer is seeded by the 9x specific code. Seems like that block of code just needs a backport from win9x_get_connection to set the server side of this structure correctly before it's copied into sockinfo later in the same function. I can't easily build it and not sure what other non-acceptex 9x-isms are in win9x_get_connection. This matches the reports of the base VH being picked every time, but I couldn't find on the list where the culprit had been identified before.
[VOTE] Release Tomcat 5.5.34 Build
The builds for Tomcat 5.5.34 are ready for testing and approval. The candidates binaries are available here: http://people.apache.org/~jim/tomcat-5.5/ According to the release process, the 5.5.34 build corresponding to the tag TOMCAT_5_5_34 [1] is: [ ] Broken [ ] Alpha [ ] Beta [ ] Stable +++ 1. http://svn.apache.org/viewvc/tomcat/tc5.5.x/tags/TOMCAT_5_5_34/
Re: mod_cache incompatible with efficient PHP?
On 18 Sep 2011, at 7:36 AM, Bill Lipa wrote: According to this thread on serverfault: http://serverfault.com/questions/74025/apaches-mod-cache-not-caching-fcgi-php-output and this dormant bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=48364 the use of Action directives to handle php requests (or indeed any type of request) breaks mod_cache. I believe Action is a key part of the standard / recommended way to use php with fcgi, and fcgi is needed for even moderate efficiency. Being able to use mod_cache with PHP seems like a pretty important use case. Is there hope for an Apache-only caching solution for php sites? Reading through this bug again, this looks like a filter problem rather than a mod_cache problem. To solve this, you would need to confirm whether the filter stack is not being bypassed or otherwise being fiddled with during the request by the handler you're using (mod_fastcgi?). The debug log shows the cache filters being added, but then silence, which in most cases means the filters like mod_cache never got the chance to run. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Release Tomcat 5.5.34 Build
On Sep 18, 2011, at 3:26 PM, Jim Jagielski wrote: The builds for Tomcat 5.5.34 ignore… sorry :)
Re: Pushing for httpd 2.4.0 GA
On Sep 17, 2011, at 10:02 PM, Rich Bowen wrote: On Sep 15, 2011, at 9:01 AM, Jim Jagielski wrote: I plan on push for a GA in Oct (of this year)… The only 2 showstoppers I see as reasonable are the documentation ones and the mod_fcgid one. Could you enumerate what you feel is lacking in the documentation? I know of several modules that are effectively undocumented, and a few more that have minimal, but insufficient documentation. I'd like to hear your take on this. As always, I'm willing to whatever I can on the editing, formatting, etc, side of things, but the raw info needs to come from somewhere. Please let me know where I can be of assistance. Just the possible fact that some modules may not have doccos… Not sure if that is even the case (yet), but if there are mod's w/o docs, then we can't in good conscience ship the mods.
Re: Pushing for httpd 2.4.0 GA
On Sep 18, 2011, at 5:12 PM, Jim Jagielski wrote: On Sep 17, 2011, at 10:02 PM, Rich Bowen wrote: On Sep 15, 2011, at 9:01 AM, Jim Jagielski wrote: I plan on push for a GA in Oct (of this year)… The only 2 showstoppers I see as reasonable are the documentation ones and the mod_fcgid one. Could you enumerate what you feel is lacking in the documentation? I know of several modules that are effectively undocumented, and a few more that have minimal, but insufficient documentation. I'd like to hear your take on this. As always, I'm willing to whatever I can on the editing, formatting, etc, side of things, but the raw info needs to come from somewhere. Please let me know where I can be of assistance. Just the possible fact that some modules may not have doccos… Not sure if that is even the case (yet), but if there are mod's w/o docs, then we can't in good conscience ship the mods. My current list is: - mod_serf - mod_watchdog - mod_heartbeat - mod_heartmonitor - mod_lbmethod_bybusyness - mod_lbmethod_byrequests - mod_lbmethod_bytraffic - mod_lbmethod_heartbeat - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb - mpm_simple However, I will readily admit that I haven't had much time to work on docs the last month or two, so some of these many have been documented since then, and there may be others that I'm missing. There's also mod_lua, which has many directives documented with ..., and I suspect that there are other modules in this same state. -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Re: Pushing for httpd 2.4.0 GA
On 19.09.2011 00:17, Rich Bowen wrote: My current list is: - mod_serf mod_serf likely to get dropped for 2.4, see our main STATUS file - mod_watchdog Mainly written by Mladen, so maybe he can provide a few pointers - mod_heartbeat - mod_heartmonitor Those two were mainly provided by Jean-Frederic (AFAIR). - mod_lbmethod_bybusyness - mod_lbmethod_byrequests - mod_lbmethod_bytraffic - mod_lbmethod_heartbeat Several people (including me) should be easily able to contribute to those docs. - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb Not sure about socache, but docs are definitely needed, because you need socache for mod_ssl session cache (which we also need to mention int the mod_ssl docs). - mpm_simple mpm_simple likely to get dropped for 2.4, see our main STATUS file However, I will readily admit that I haven't had much time to work on docs the last month or two, so some of these many have been documented since then, and there may be others that I'm missing. There's also mod_lua, which has many directives documented with ..., and I suspect that there are other modules in this same state. Regards, Rainer
Re: Pushing for httpd 2.4.0 GA
On Mon, 19 Sep 2011 00:52:34 +0200 Rainer Jung rainer.j...@kippdata.de wrote: - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb Not sure about socache, but docs are definitely needed, because you need socache for mod_ssl session cache (which we also need to mention int the mod_ssl docs). These modules are implementations of an abstraction, and probably don't want standard module pages. Like mod_proxy_foo backends. Maybe this can serve as a startingpoint for socache docs: http://httpd.apache.org/docs/2.3/socache.html (I had an idea I'd written some socache docs when I wrote mod_authn_socache, but I suspect it was no more than the above). -- Nick Kew
PATCH: mod_log_config, CookieLog
The CookieLog directive has been documented as deprecated since mod_log_config
was introduced, back in the 1.2 days. Any objection to axing it?
Index: docs/manual/mod/mod_log_config.xml
===
--- docs/manual/mod/mod_log_config.xml (revision 1172391)
+++ docs/manual/mod/mod_log_config.xml (working copy)
@@ -361,23 +361,6 @@
/directivesynopsis
directivesynopsis
-nameCookieLog/name
-descriptionSets filename for the logging of cookies/description
-syntaxCookieLog varfilename/var/syntax
-contextlistcontextserver config/contextcontextvirtual host/context
-/contextlist
-compatibilityThis directive is deprecated./compatibility
-
-usage
-pThe directiveCookieLog/directive directive sets the
-filename for logging of cookies. The filename is relative to the
-directive module=coreServerRoot/directive. This directive is
-included only for compatibility with codemod_cookies/code,
-and is deprecated./p
-/usage
-/directivesynopsis
-
-directivesynopsis
nameCustomLog/name
descriptionSets filename and format of log file/description
syntaxCustomLog varfile/var|varpipe/var
Index: modules/loggers/mod_log_config.c
===
--- modules/loggers/mod_log_config.c(revision 1172391)
+++ modules/loggers/mod_log_config.c(working copy)
@@ -31,9 +31,6 @@
*Log to file fn with format given by the format
*argument
*
- *CookieLog fnFor backwards compatability with old Cookie
- *logging module - now deprecated.
- *
* There can be any number of TransferLog and CustomLog
* commands. Each request will be logged to _ALL_ the
* named files, in the appropriate format.
@@ -1284,11 +1281,6 @@
return add_custom_log(cmd, dummy, fn, NULL, NULL);
}
-static const char *set_cookie_log(cmd_parms *cmd, void *dummy, const char *fn)
-{
-return add_custom_log(cmd, dummy, fn, %{Cookie}n \%r\ %t, NULL);
-}
-
static const char *set_buffered_logs_on(cmd_parms *parms, void *dummy, int
flag)
{
buffered_logs = flag;
@@ -1311,8 +1303,6 @@
the filename of the access log),
AP_INIT_TAKE12(LogFormat, log_format, NULL, RSRC_CONF,
a log format string (see docs) and an optional format name),
-AP_INIT_TAKE1(CookieLog, set_cookie_log, NULL, RSRC_CONF,
- the filename of the cookie log),
AP_INIT_FLAG(BufferedLogs, set_buffered_logs_on, NULL, RSRC_CONF,
Enable Buffered Logging (experimental)),
{NULL}
--
Rich Bowen
rbo...@rcbowen.com
rbo...@apache.org
Re: Pushing for httpd 2.4.0 GA
On Sep 18, 2011, at 7:16 PM, Nick Kew wrote: - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb Not sure about socache, but docs are definitely needed, because you need socache for mod_ssl session cache (which we also need to mention int the mod_ssl docs). These modules are implementations of an abstraction, and probably don't want standard module pages. Like mod_proxy_foo backends. Excellent. I wondered if they were in that category. The list was produced from a simple grep. I'll remove those from my list, and see if I can find any that I missed, or which are new since I made the original list. -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Re: Pushing for httpd 2.4.0 GA
On 19.09.2011 01:37, Rich Bowen wrote: On Sep 18, 2011, at 7:16 PM, Nick Kew wrote: - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb Not sure about socache, but docs are definitely needed, because you need socache for mod_ssl session cache (which we also need to mention int the mod_ssl docs). These modules are implementations of an abstraction, and probably don't want standard module pages. Like mod_proxy_foo backends. Excellent. I wondered if they were in that category. The list was produced from a simple grep. I'll remove those from my list, and see if I can find any that I missed, or which are new since I made the original list. I think we need to add to the mod_ssl docs, that if you want an ssl session cache (and yes, you want one although most modern clients support reusing the session without caching session data on the server side - it's a TLS extension OpenSSL/mod_ssl supports), you need to activate mod_socache_xxx where xxx depends on the SSLSessionCache you configure (maybe we need a table or similar). There is a short remark on the socache page, that it is used by other modules, but a user would expect a remark in the pages of the other mdules, that you need to activate the correct socache module. Regards, Rainer
Re: svn commit: r1172010 - /httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
On 09/17/2011 06:25 PM, drugg...@apache.org wrote:
Author: druggeri
Date: Sat Sep 17 16:25:17 2011
New Revision: 1172010
URL: http://svn.apache.org/viewvc?rev=1172010view=rev
Log:
Log better information and prevent leak of an X509 structure for
SSLProxyMachineCertificateChainFile
Modified:
httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?rev=1172010r1=1172009r2=1172010view=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_engine_init.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_init.c Sat Sep 17 16:25:17 2011
@@ -1181,21 +1181,57 @@ static void ssl_init_proxy_certs(server_
X509_STORE_load_locations(store, pkp-ca_cert_file, NULL);
for (n = 0; n ncerts; n++) {
-int i;
+int i, res;
+char cert_cn[256];
+
X509_INFO *inf = sk_X509_INFO_value(pkp-certs, n);
+X509_NAME *name = X509_get_subject_name(inf-x509);
+X509_NAME_oneline(name, cert_cn, sizeof(cert_cn));
X509_STORE_CTX_init(sctx, store, inf-x509, NULL);
-X509_verify_cert(sctx);
-ERR_clear_error();
+res=X509_verify_cert(sctx);
Style violation.
chain = X509_STORE_CTX_get1_chain(sctx);
-sk_X509_shift(chain);
+
+if (res == 1) {
+/* Removing the client cert if verification is OK
+ * could save a loop when choosing which cert to send
+ * when more than one is available */
+/* XXX: This is not needed if we collapse the two
+ * checks in ssl_engine_kernel in the future */
+X509_free(sk_X509_shift(chain));
+}
+else {
+int n=X509_STORE_CTX_get_error(sctx);
Overwriting a symbol from the loop is IMHO bad and makes code hard to read.
Please use
another name instead of n. Besides we have a style violation here again.
+ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s,
+ SSL proxy client cert chain verification failed
for %s: %s,
+ cert_cn, X509_verify_cert_error_string(n));
+}
+ERR_clear_error();
i=sk_X509_num(chain);
pkp-ca_certs[n] = chain;
+
+if (i == 0 || (res != 1 i == 1) ) {
+/* zero or only the client cert won't be very useful
+ * due to verification failure */
+sk_X509_pop_free(chain, X509_free);
+i = 0;
+pkp-ca_certs[n] = NULL;
+}
+
X509_STORE_CTX_cleanup(sctx);
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
- client certificate %i has loaded %i
- intermediate CA%s, n, i, i == 1 ? : s);
+ loaded %i intermediate CA%s for cert %i (%s),
+ i, i == 1 ? : s, n, cert_cn);
+if (i 0) {
+int j;
+for (j=0; ji; j++) {
+char ca_cn[256];
+X509_NAME *ca_name =
X509_get_subject_name(sk_X509_value(chain, j));
+X509_NAME_oneline(ca_name, ca_cn, sizeof(ca_cn));
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, %i: %s, j,
ca_cn);
+}
+}
}
X509_STORE_CTX_free(sctx);
Regards
Rüdiger
