mod_proxy_fdpass + httpd-2.2.19
Hi, I'm trying to back-port Apache Module mod_proxy_fdpass to httpd-2.2.19, and building from source, but are getting the following error message when starting apachectl: httpd: Module (null) is not compatible with this version of Apache (found 0, need 20051115). Please contact the vendor for the correct version. I've been googling an answer but only found that I should contact the module vendor, which in this case would be me?! =) How can I fix this? Thanks in advance. Best Regards, Henrik
RE: mod_proxy_fdpass + httpd-2.2.19
From: Henrik Strand [mailto:henrik.str...@axis.com] Sent: Wednesday, 3 August 2011 5:10 PM To: modules-dev@httpd.apache.org Subject: mod_proxy_fdpass + httpd-2.2.19 Hi, I'm trying to back-port Apache Module mod_proxy_fdpass to httpd-2.2.19, and building from source, but are getting the following error message when starting apachectl: httpd: Module (null) is not compatible with this version of Apache (found 0, need 20051115). Please contact the vendor for the correct version. I've been googling an answer but only found that I should contact the module vendor, which in this case would be me?! =) How can I fix this? Thanks in advance. Best Regards, Henrik Does the module data that you pass to ap_get_module_config() have the constants MODULE_MAGIC_NUMBER_MAJOR and MODULE_MAGIC_NUMBER_MINOR in the first two elements? I think that is where the 20051115 should be coming from. The module name should be in that structure too. Maybe you are using compiler switches that are making int be 32 bit instead of 64 bit--thus confusing the data in the structure?
Re: mod_proxy_fdpass + httpd-2.2.19
On 3 Aug 2011, at 08:10, Henrik Strand wrote: Hi, I'm trying to back-port Apache Module mod_proxy_fdpass to httpd-2.2.19, and building from source, but are getting the following error message when starting apachectl: httpd: Module (null) is not compatible with this version of Apache (found 0, need 20051115). Please contact the vendor for the correct version. Guessing in the dark You declare the module with module AP_MODULE_DECLARE_DATA proxy_fdpass_module; But you don't instantiate it. The macro commonly used in trunk doesn't exist in 2.2. -- Nick Kew
Re: mod_proxy_fdpass + httpd-2.2.19
On 3 Aug 2011, at 09:27, Henrik Strand wrote:
module AP_MODULE_DECLARE_DATA proxy_fdpass = {
STANDARD20_MODULE_STUFF,
NULL, /* create per-directory config structure
*/
NULL, /* merge per-directory config structures
*/
NULL, /* create per-server config structure */
NULL, /* merge per-server config structures */
NULL, /* command apr_table_t */
register_hooks /* register hooks */
};
That should be fine, compiled against the right (2.2.x) headers.
--
Nick Kew
Re: mod_proxy_fdpass + httpd-2.2.19
Hmm, but this is how the code looks like when I get the error that I
posted.
Is the module initialization done with the below code, or do I need to
add that explicitly?
Best Regards,
Henrik
On Wed, 2011-08-03 at 10:41 +0200, Nick Kew wrote:
On 3 Aug 2011, at 09:27, Henrik Strand wrote:
module AP_MODULE_DECLARE_DATA proxy_fdpass = {
STANDARD20_MODULE_STUFF,
NULL, /* create per-directory config structure
*/
NULL, /* merge per-directory config structures
*/
NULL, /* create per-server config structure */
NULL, /* merge per-server config structures */
NULL, /* command apr_table_t */
register_hooks /* register hooks */
};
That should be fine, compiled against the right (2.2.x) headers.
Re: Problem in mod_deflate
On Tuesday 02 August 2011, Torsten Förtsch wrote: I don't know how common this situation is. It came up in the modperl test suite (t/filter/both_str_req_mix.t). This test contructs a filter chain like modperl filter INCLUDES another modperl filter DEFLATE The INCLUDES filter was passed a brigade containing a data bucket with single SSI command like !--#include virtual=... -- and a flush bucket. mod_include then tries to find the !--# sequence and splits the bucket before this string. Thus, it gets a bucket with an empty string. I am not sure if this bucket was delivered in a separate brigade to the DEFLATE filter and the flush bucket in the next one or if it was accompanied by the flush bucket. Although I can think of usage cases where it is common to send a flush bucket in the first place just to get the headers out I can't think of a way to make this happen with core httpd modules. So, I don't know if it qualifies for a showstopper for 2.3.14 beta. Thanks for the detailed information. Since I also know no way to trigger this bug in normal setups, I think it should not be a blocker for beta. BTW, I filed another simple bug https://issues.apache.org/bugzilla/show_bug.cgi?id=51592 which was also triggered by the modperl test suite. What are the chances for it to get applied? Fixed. Thanks again.
RE: mod_proxy_ajp: ignoring flush before headers (again)
Can you please try if the following patch fixes your issue?
Index: mod_proxy_ajp.c
===
--- mod_proxy_ajp.c (revision 1150558)
+++ mod_proxy_ajp.c (working copy)
@@ -506,16 +506,18 @@
if (bb_len != -1)
conn-worker-s-read += bb_len;
}
-if (ap_pass_brigade(r-output_filters,
-output_brigade) != APR_SUCCESS) {
-ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
- proxy: error processing body.%s,
- r-connection-aborted ?
- Client aborted connection. : );
-output_failed = 1;
+if (headers_sent) {
+if (ap_pass_brigade(r-output_filters,
+output_brigade) !=
APR_SUCCESS) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+ proxy: error processing
body.%s,
+ r-connection-aborted ?
+ Client aborted connection. :
);
+output_failed = 1;
+}
+data_sent = 1;
+apr_brigade_cleanup(output_brigade);
}
-data_sent = 1;
-apr_brigade_cleanup(output_brigade);
}
}
else {
Currently the code sends an empty brigade in your case which also triggers the
sending of headers by httpd.
Regards
Rüdiger
-Original Message-
From: Jim Riggs
Sent: Dienstag, 2. August 2011 18:03
To: dev@httpd.apache.org
Subject: mod_proxy_ajp: ignoring flush before headers (again)
For some (old 2007) context, see:
http://markmail.org/message/btwcnbl2i7ftwj4n
https://community.jivesoftware.com/message/201787
I am proxying an app via AJP to Tomcat 6/7. In certain
circumstances, it appears that the app (or possibly Tomcat)
is erroneously sending a flush before the headers have been
sent. In r57, Jim added an exception to handle this
situation with the intention of ignoring the flush. I'm not
sure it's working quite right, though, as the brigade is
still getting passed through the filter chain. So,
ap_headers_output_filter() is getting called too soon, I
think. (I am no expert in the httpd code, so I'm not sure
this is really the problem.)
Can any of you who ARE experts in the code tell me what you
think of the issue and how we can fix it? I'm thinking that
if we are ignoring a flush at mod_proxy_ajp.c:448 (in 2.2.x),
we should not be calling ap_pass_brigade() at line 472, but I
don't know if there are any ramifications of that.
The symptom is that when this issue happens, the user gets
prompted to save a file (Content-Type returned by httpd is
'text/plain' even though Tomcat is returning
'text/html;charset=utf-8'). Below is some debug output
showing correct and incorrect behavior:
Correct:
[Tue Aug 02 09:34:50 2011] [debug] mod_proxy_ajp.c(266):
proxy: APR_BUCKET_IS_EOS
[Tue Aug 02 09:34:50 2011] [debug] mod_proxy_ajp.c(271):
proxy: data to read (max 8186 at 4)
[Tue Aug 02 09:34:50 2011] [debug] mod_proxy_ajp.c(286):
proxy: got 0 bytes of data
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(687):
ajp_read_header: ajp_ilink_received 04
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(697):
ajp_parse_type: got 04
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(516):
ajp_unmarshal_response: status = 200
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(537):
ajp_unmarshal_response: Number of headers is = 5
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(599):
ajp_unmarshal_response: Header[0] [Pragma] = [No-cache]
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(599):
ajp_unmarshal_response: Header[1] [Cache-Control] = [no-cache]
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(599):
ajp_unmarshal_response: Header[2] [Expires] = [Wed, 31 Dec
1969 18:00:00 CST]
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(599):
ajp_unmarshal_response: Header[4] [Content-Type] =
[text/html;charset=utf-8]
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(609):
ajp_unmarshal_response: ap_set_content_type done
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(687):
ajp_read_header: ajp_ilink_received 03
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(697):
ajp_parse_type: got 03
[Tue Aug 02 09:34:50 2011] [debug] mod_headers.c(756):
headers: ap_headers_output_filter()
Incorrect (notice how ap_headers_output_filter() is called
before the headers are received):
Windows Binary 2.3.14 public beta available for testing
See http://www.apachelounge.com/
Re: mod_proxy_ajp: ignoring flush before headers (again)
This does appear to work. Our automated tests are running right now. Shall I
submit a but with this patch attached?
On Aug 3, 2011, at 7:43 AM, Plüm, Rüdiger, VF-Group wrote:
Can you please try if the following patch fixes your issue?
Index: mod_proxy_ajp.c
===
--- mod_proxy_ajp.c (revision 1150558)
+++ mod_proxy_ajp.c (working copy)
@@ -506,16 +506,18 @@
if (bb_len != -1)
conn-worker-s-read += bb_len;
}
-if (ap_pass_brigade(r-output_filters,
-output_brigade) != APR_SUCCESS) {
-ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
- proxy: error processing body.%s,
- r-connection-aborted ?
- Client aborted connection. :
);
-output_failed = 1;
+if (headers_sent) {
+if (ap_pass_brigade(r-output_filters,
+output_brigade) !=
APR_SUCCESS) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+ proxy: error processing
body.%s,
+ r-connection-aborted ?
+ Client aborted connection.
: );
+output_failed = 1;
+}
+data_sent = 1;
+apr_brigade_cleanup(output_brigade);
}
-data_sent = 1;
-apr_brigade_cleanup(output_brigade);
}
}
else {
Currently the code sends an empty brigade in your case which also triggers
the sending of headers by httpd.
Regards
Rüdiger
-Original Message-
From: Jim Riggs
Sent: Dienstag, 2. August 2011 18:03
To: dev@httpd.apache.org
Subject: mod_proxy_ajp: ignoring flush before headers (again)
For some (old 2007) context, see:
http://markmail.org/message/btwcnbl2i7ftwj4n
https://community.jivesoftware.com/message/201787
I am proxying an app via AJP to Tomcat 6/7. In certain
circumstances, it appears that the app (or possibly Tomcat)
is erroneously sending a flush before the headers have been
sent. In r57, Jim added an exception to handle this
situation with the intention of ignoring the flush. I'm not
sure it's working quite right, though, as the brigade is
still getting passed through the filter chain. So,
ap_headers_output_filter() is getting called too soon, I
think. (I am no expert in the httpd code, so I'm not sure
this is really the problem.)
Can any of you who ARE experts in the code tell me what you
think of the issue and how we can fix it? I'm thinking that
if we are ignoring a flush at mod_proxy_ajp.c:448 (in 2.2.x),
we should not be calling ap_pass_brigade() at line 472, but I
don't know if there are any ramifications of that.
The symptom is that when this issue happens, the user gets
prompted to save a file (Content-Type returned by httpd is
'text/plain' even though Tomcat is returning
'text/html;charset=utf-8'). Below is some debug output
showing correct and incorrect behavior:
Correct:
[Tue Aug 02 09:34:50 2011] [debug] mod_proxy_ajp.c(266):
proxy: APR_BUCKET_IS_EOS
[Tue Aug 02 09:34:50 2011] [debug] mod_proxy_ajp.c(271):
proxy: data to read (max 8186 at 4)
[Tue Aug 02 09:34:50 2011] [debug] mod_proxy_ajp.c(286):
proxy: got 0 bytes of data
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(687):
ajp_read_header: ajp_ilink_received 04
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(697):
ajp_parse_type: got 04
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(516):
ajp_unmarshal_response: status = 200
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(537):
ajp_unmarshal_response: Number of headers is = 5
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(599):
ajp_unmarshal_response: Header[0] [Pragma] = [No-cache]
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(599):
ajp_unmarshal_response: Header[1] [Cache-Control] = [no-cache]
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(599):
ajp_unmarshal_response: Header[2] [Expires] = [Wed, 31 Dec
1969 18:00:00 CST]
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(599):
ajp_unmarshal_response: Header[4] [Content-Type] =
[text/html;charset=utf-8]
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(609):
ajp_unmarshal_response: ap_set_content_type done
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(687):
ajp_read_header: ajp_ilink_received 03
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(697):
Re: [VOTE] Release httpd-2.3.14 as beta
On Monday 01 August 2011, Jim Jagielski wrote: The tarballs for httpd-2.3.14 are available at: http://httpd.apache.org/dev/dist/ Please VOTE on whether to release these as Apache httpd-2.3.14, beta. +1: release as beta Issues found (which are IMHO non-blockers): The mod_deflate endless loop (PR 51590). Sorry about that. I was on vacation for a few days and couldn't react to Torsten's mail sooner. As noted in a different mail, I don't think this is triggered in normal operation and should therefore not be a blocker. Generated docs not up-to-date. Compilation fails with --enable-modules=reallyall if apr-util does not have ldap support. Instead, the ldap modules should simply be disabled. I don't think this is a regression and reallyall is mainly for developers, anyway. 'all' works OK. Therefore no blocker. Will fix this in the next few days.
RE: mod_proxy_ajp: ignoring flush before headers (again)
Thanks for testing. Committed to trunk as r1153531.
A bug report mentioning the trunk revision could be handy as a backport tracker
for 2.2.x.
Regards
Rüdiger
-Original Message-
From: Jim Riggs
Sent: Mittwoch, 3. August 2011 16:48
To: dev@httpd.apache.org
Subject: Re: mod_proxy_ajp: ignoring flush before headers (again)
This does appear to work. Our automated tests are running
right now. Shall I submit a but with this patch attached?
On Aug 3, 2011, at 7:43 AM, Plüm, Rüdiger, VF-Group wrote:
Can you please try if the following patch fixes your issue?
Index: mod_proxy_ajp.c
===
--- mod_proxy_ajp.c (revision 1150558)
+++ mod_proxy_ajp.c (working copy)
@@ -506,16 +506,18 @@
if (bb_len != -1)
conn-worker-s-read += bb_len;
}
-if (ap_pass_brigade(r-output_filters,
-
output_brigade) != APR_SUCCESS) {
-ap_log_rerror(APLOG_MARK,
APLOG_DEBUG, 0, r,
- proxy: error
processing body.%s,
- r-connection-aborted ?
- Client aborted
connection. : );
-output_failed = 1;
+if (headers_sent) {
+if (ap_pass_brigade(r-output_filters,
+
output_brigade) != APR_SUCCESS) {
+ap_log_rerror(APLOG_MARK,
APLOG_DEBUG, 0, r,
+ proxy:
error processing body.%s,
+
r-connection-aborted ?
+ Client
aborted connection. : );
+output_failed = 1;
+}
+data_sent = 1;
+apr_brigade_cleanup(output_brigade);
}
-data_sent = 1;
-apr_brigade_cleanup(output_brigade);
}
}
else {
Currently the code sends an empty brigade in your case
which also triggers the sending of headers by httpd.
Regards
Rüdiger
-Original Message-
From: Jim Riggs
Sent: Dienstag, 2. August 2011 18:03
To: dev@httpd.apache.org
Subject: mod_proxy_ajp: ignoring flush before headers (again)
For some (old 2007) context, see:
http://markmail.org/message/btwcnbl2i7ftwj4n
https://community.jivesoftware.com/message/201787
I am proxying an app via AJP to Tomcat 6/7. In certain
circumstances, it appears that the app (or possibly Tomcat)
is erroneously sending a flush before the headers have been
sent. In r57, Jim added an exception to handle this
situation with the intention of ignoring the flush. I'm not
sure it's working quite right, though, as the brigade is
still getting passed through the filter chain. So,
ap_headers_output_filter() is getting called too soon, I
think. (I am no expert in the httpd code, so I'm not sure
this is really the problem.)
Can any of you who ARE experts in the code tell me what you
think of the issue and how we can fix it? I'm thinking that
if we are ignoring a flush at mod_proxy_ajp.c:448 (in 2.2.x),
we should not be calling ap_pass_brigade() at line 472, but I
don't know if there are any ramifications of that.
The symptom is that when this issue happens, the user gets
prompted to save a file (Content-Type returned by httpd is
'text/plain' even though Tomcat is returning
'text/html;charset=utf-8'). Below is some debug output
showing correct and incorrect behavior:
Correct:
[Tue Aug 02 09:34:50 2011] [debug] mod_proxy_ajp.c(266):
proxy: APR_BUCKET_IS_EOS
[Tue Aug 02 09:34:50 2011] [debug] mod_proxy_ajp.c(271):
proxy: data to read (max 8186 at 4)
[Tue Aug 02 09:34:50 2011] [debug] mod_proxy_ajp.c(286):
proxy: got 0 bytes of data
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(687):
ajp_read_header: ajp_ilink_received 04
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(697):
ajp_parse_type: got 04
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(516):
ajp_unmarshal_response: status = 200
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(537):
ajp_unmarshal_response: Number of headers is = 5
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(599):
ajp_unmarshal_response: Header[0] [Pragma] = [No-cache]
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(599):
ajp_unmarshal_response: Header[1] [Cache-Control] = [no-cache]
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(599):
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
On 02.08.2011 22:39, William A. Rowe Jr. wrote: On 7/31/2011 4:17 AM, Kaspar Brand wrote: - drop support for OpenSSL 0.9.7a - drop support for non-OpenSSL/derivatives of OpenSSL Ok, then my next step is working on a patch which takes care of these two points, I guess. +1 Ok, so the initial version of that patch became relatively large: https://people.apache.org/~kbrand/mod_ssl-toolkit-support.v1.diff Even though trunk is CTR, I'm somewhat reluctant with simply going ahead and would appreciate if people could comment on this approach (e.g. if it's fine or splitting up would be preferred, etc.). In theory, the changes could be limited to the autoconf stuff - i.e., guard against OpenSSL 0.9.7 and not detect BSAFE SSL-C any longer in configure, and leave the mod_ssl code as is, mostly. I don't think that's what we want, however, so I tried to get rid of as much of the macro cruft as possible (drop ssl_toolkit_compat.h, remove obsolete ifdef'ed code and so on). I successfully compiled trunk with the above patch against the following OpenSSL versions (w/o warnings): 0.9.7, 0.9.8, 1.0.0d (NB: by 0.9.7, I'm referring to the initial release in that series, not the 0.9.7a patch release). Finally, I also ran the t/ssl tests against the three versions with these OpenSSL releases, and all of them passed. Thanks for commenting on / reviewing the current patch version. Kaspar
Re: mod_proxy_ajp: ignoring flush before headers (again)
https://issues.apache.org/bugzilla/show_bug.cgi?id=51608
Thank you for your help and quick fix, Rüdiger!!
On Aug 3, 2011, at 10:09 AM, Plüm, Rüdiger, VF-Group wrote:
Thanks for testing. Committed to trunk as r1153531.
A bug report mentioning the trunk revision could be handy as a backport
tracker for 2.2.x.
Regards
Rüdiger
-Original Message-
From: Jim Riggs
Sent: Mittwoch, 3. August 2011 16:48
To: dev@httpd.apache.org
Subject: Re: mod_proxy_ajp: ignoring flush before headers (again)
This does appear to work. Our automated tests are running
right now. Shall I submit a but with this patch attached?
On Aug 3, 2011, at 7:43 AM, Plüm, Rüdiger, VF-Group wrote:
Can you please try if the following patch fixes your issue?
Index: mod_proxy_ajp.c
===
--- mod_proxy_ajp.c (revision 1150558)
+++ mod_proxy_ajp.c (working copy)
@@ -506,16 +506,18 @@
if (bb_len != -1)
conn-worker-s-read += bb_len;
}
-if (ap_pass_brigade(r-output_filters,
-
output_brigade) != APR_SUCCESS) {
-ap_log_rerror(APLOG_MARK,
APLOG_DEBUG, 0, r,
- proxy: error
processing body.%s,
- r-connection-aborted ?
- Client aborted
connection. : );
-output_failed = 1;
+if (headers_sent) {
+if (ap_pass_brigade(r-output_filters,
+
output_brigade) != APR_SUCCESS) {
+ap_log_rerror(APLOG_MARK,
APLOG_DEBUG, 0, r,
+ proxy:
error processing body.%s,
+
r-connection-aborted ?
+ Client
aborted connection. : );
+output_failed = 1;
+}
+data_sent = 1;
+apr_brigade_cleanup(output_brigade);
}
-data_sent = 1;
-apr_brigade_cleanup(output_brigade);
}
}
else {
Currently the code sends an empty brigade in your case
which also triggers the sending of headers by httpd.
Regards
Rüdiger
-Original Message-
From: Jim Riggs
Sent: Dienstag, 2. August 2011 18:03
To: dev@httpd.apache.org
Subject: mod_proxy_ajp: ignoring flush before headers (again)
For some (old 2007) context, see:
http://markmail.org/message/btwcnbl2i7ftwj4n
https://community.jivesoftware.com/message/201787
I am proxying an app via AJP to Tomcat 6/7. In certain
circumstances, it appears that the app (or possibly Tomcat)
is erroneously sending a flush before the headers have been
sent. In r57, Jim added an exception to handle this
situation with the intention of ignoring the flush. I'm not
sure it's working quite right, though, as the brigade is
still getting passed through the filter chain. So,
ap_headers_output_filter() is getting called too soon, I
think. (I am no expert in the httpd code, so I'm not sure
this is really the problem.)
Can any of you who ARE experts in the code tell me what you
think of the issue and how we can fix it? I'm thinking that
if we are ignoring a flush at mod_proxy_ajp.c:448 (in 2.2.x),
we should not be calling ap_pass_brigade() at line 472, but I
don't know if there are any ramifications of that.
The symptom is that when this issue happens, the user gets
prompted to save a file (Content-Type returned by httpd is
'text/plain' even though Tomcat is returning
'text/html;charset=utf-8'). Below is some debug output
showing correct and incorrect behavior:
Correct:
[Tue Aug 02 09:34:50 2011] [debug] mod_proxy_ajp.c(266):
proxy: APR_BUCKET_IS_EOS
[Tue Aug 02 09:34:50 2011] [debug] mod_proxy_ajp.c(271):
proxy: data to read (max 8186 at 4)
[Tue Aug 02 09:34:50 2011] [debug] mod_proxy_ajp.c(286):
proxy: got 0 bytes of data
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(687):
ajp_read_header: ajp_ilink_received 04
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(697):
ajp_parse_type: got 04
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(516):
ajp_unmarshal_response: status = 200
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(537):
ajp_unmarshal_response: Number of headers is = 5
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(599):
ajp_unmarshal_response: Header[0] [Pragma] = [No-cache]
[Tue Aug 02 09:34:50 2011] [debug] ajp_header.c(599):
ajp_unmarshal_response: Header[1] [Cache-Control] = [no-cache]
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
On 8/3/2011 11:23 AM, Kaspar Brand wrote: Ok, so the initial version of that patch became relatively large: https://people.apache.org/~kbrand/mod_ssl-toolkit-support.v1.diff Even though trunk is CTR, I'm somewhat reluctant with simply going ahead and would appreciate if people could comment on this approach (e.g. if it's fine or splitting up would be preferred, etc.). In theory, the changes could be limited to the autoconf stuff - i.e., guard against OpenSSL 0.9.7 and not detect BSAFE SSL-C any longer in configure, and leave the mod_ssl code as is, mostly. I don't think that's what we want, however, so I tried to get rid of as much of the macro cruft as possible (drop ssl_toolkit_compat.h, remove obsolete ifdef'ed code and so on). My thought, it probably should be a set of commits; * Drop SSLC (first patch) * Drop OpenSSL 0.9.7 (second patch) * Drop ssl_toolkit_compat wrapper (third patch) * Warn on 0.9.7 and some 0.9.8 flavors (last patch)
Re: mod_ssl in trunk with OpenSSL 0.9.7 as a minimum requirement?
On 03/08/2011 18:08, William A. Rowe Jr. wrote: On 8/3/2011 11:23 AM, Kaspar Brand wrote: Ok, so the initial version of that patch became relatively large: https://people.apache.org/~kbrand/mod_ssl-toolkit-support.v1.diff Even though trunk is CTR, I'm somewhat reluctant with simply going ahead and would appreciate if people could comment on this approach (e.g. if it's fine or splitting up would be preferred, etc.). In theory, the changes could be limited to the autoconf stuff - i.e., guard against OpenSSL 0.9.7 and not detect BSAFE SSL-C any longer in configure, and leave the mod_ssl code as is, mostly. I don't think that's what we want, however, so I tried to get rid of as much of the macro cruft as possible (drop ssl_toolkit_compat.h, remove obsolete ifdef'ed code and so on). My thought, it probably should be a set of commits; * Drop SSLC (first patch) * Drop OpenSSL 0.9.7 (second patch) * Drop ssl_toolkit_compat wrapper (third patch) * Warn on 0.9.7 and some 0.9.8 flavors (last patch) A data point for this effort which may be of interest... In OpenSSL 1.0.1 (unreleased) and later there is a feature to make all SSL related structures opaque and only allow them to be accessed through functions. This is enabled by setting OPENSSL_NO_SSL_INTERN before including any OpenSSL headers. The advantage of this is that any application which can be compiled with this option will retain binary compatibility through any changes to SSL internal structures. I haven't had time to try getting mod_ssl to work with this option. It is guaranteed to fail without some modification. There may well be some functionality missing in OpenSSL too. Ironically to support this you'd need to avoid some of the changes in this patch. For example: -l = strlen(SSL_CIPHER_get_name(c)); -memcpy(cp, SSL_CIPHER_get_name(c), l); +l = strlen(c-name); +memcpy(cp, c-name, l); Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [VOTE] Release httpd-2.3.14 as beta
+1 for beta Windows x86 x64 XP, Vista x86 Server 2008 R2
