Re: [PATCH] make test TEST_VERBOSE=1
On Wed, 18 Sep 2002, Doug MacEachern wrote: > On Wed, 18 Sep 2002, Geoffrey Young wrote: > > > I think the attached patch behaves as suggested. > > perfectly, thanks. with 5.8.0 that is. with 5.6.1, dies with: Error in option spec: "verbose:1" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] make test TEST_VERBOSE=1
On Wed, 18 Sep 2002, Geoffrey Young wrote: > I think the attached patch behaves as suggested. perfectly, thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
auth stuff still broken
a fresh build/install of .42-dev: Cannot load /.../modules/mod_authn_file.so into server: /.../modules/mod_authn_file.so: undefined symbol: authn_register_provider stock httpd.conf is installed (by 'make install') with modules in this order: LoadModule authn_file_module modules/mod_authn_file.so LoadModule authn_dbm_module modules/mod_authn_dbm.so LoadModule authn_anon_module modules/mod_authn_anon.so LoadModule authn_default_module modules/mod_authn_default.so LoadModule authz_host_module modules/mod_authz_host.so LoadModule authz_groupfile_module modules/mod_authz_groupfile.so LoadModule authz_user_module modules/mod_authz_user.so LoadModule authz_dbm_module modules/mod_authz_dbm.so LoadModule authz_default_module modules/mod_authz_default.so LoadModule auth_basic_module modules/mod_auth_basic.so LoadModule auth_digest_module modules/mod_auth_digest.so
Re: --with-mpm=worker on freebsd
On Tue, 11 Jun 2002, Cliff Woolley wrote: > Because threads are forced to be disabled on FreeBSD. I believe there's a > warning message about this in the ./configure output... you might just not > have noticed it as it scrolled by. that's odd, why not just abort with a message "sorry only prefork supported". anyhow, if threads are always disabled on freebsd, then APR_HAS_THREADS should always be 0, right? a guy on the modperl list compiled --with-mpm=worker on freebsd, his apr.h has: #define APR_HAS_THREADS 1 he's running freebsd 4.5-release also, aren't the thread issues solved in newer freebsd's? icarus is running FreeBSD 4.6-RC #11: Mon Jun 3 17:17:13 PDT 2002
--with-mpm=worker on freebsd
why is it on freebsd --with-mpm=worker actually compiles the prefork mpm? i just tried building on icarus with the 2.0.37 tarball, same thang with 2.0.36 % cat config.nice #! /bin/sh # # Created by configure CFLAGS="-g"; export CFLAGS "./configure" \ "--prefix=/home/dougm/apache2-worker" \ "--with-mpm=worker" \ "$@" % ~/apache2-worker/bin/httpd -V Server version: Apache/2.0.37 Server built: Jun 11 2002 10:18:20 Server's Module Magic Number: 20020602:1 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" ... % ~/apache2-worker/bin/httpd -l | grep prefork prefork.c
Re: cvs commit: httpd-2.0 CHANGES
On Mon, 10 Jun 2002, Doug MacEachern wrote: > i'd be surprised if 'SSLOptions +OptRengotiate' actually ever worked for > anybody before this change, including the 1.3 based modssl which still has > this issue. i take that back a bit, i'd be surprised if it worked for anybody using netscape 4.xx where you can see: - click on the security lock icon - click on "Navigator" there is an option here "Certificate to identify you to a website" the default is [Ask Every Time] it is only an issue in that case, where the first request prompts for client cert, any request after that with SSLSessionCache results in FORBIDDEN with the "Cannot find peer certificate chain" error_log message. this is not a problem when the netscape option is changed to [Select Automatically] which i think newer versions do by default, same with IE and likely other clients.
Re: cvs commit: httpd-2.0 CHANGES
just a note on this, SSLOptions +OptRengotiate simulates what
s3_srvr.c:ssl3_get_client_certificate would do when calling
ssl_verify_cert_chain() with the certs presented by the client.
for whatever reason, when the cert chain is saved to the session cache,
the peer cert is removed from the chain:
s->session->peer=sk_X509_shift(sk);
...
s->session->sess_cert->cert_chain=sk;
/* Inconsistency alert: cert_chain does *not* include the
* peer's own certificate, while we do include it in s3_clnt.c */
so this workaround simply pushes the peer cert from the session cache back
into the "chain".
i'd be surprised if 'SSLOptions +OptRengotiate' actually ever worked for
anybody before this change, including the 1.3 based modssl which still has
this issue.
On 11 Jun 2002 [EMAIL PROTECTED] wrote:
> dougm 2002/06/10 20:12:34
>
> Modified:modules/ssl ssl_engine_kernel.c
>.CHANGES
> Log:
> 'SSLOptions +OptRengotiate' will use client cert in from the ssl
> session cache when there is no cert chain in the cache. prior to
> the fix this situation would result in a FORBIDDEN response and
> error message "Cannot find peer certificate chain"
>
> Revision ChangesPath
> 1.73 +15 -0 httpd-2.0/modules/ssl/ssl_engine_kernel.c
>
> Index: ssl_engine_kernel.c
> ===
> RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_kernel.c,v
> retrieving revision 1.72
> retrieving revision 1.73
> diff -u -r1.72 -r1.73
> --- ssl_engine_kernel.c 4 Jun 2002 07:12:26 - 1.72
> +++ ssl_engine_kernel.c 11 Jun 2002 03:12:33 - 1.73
> @@ -709,6 +709,16 @@
>
>cert_stack = (STACK_OF(X509) *)SSL_get_peer_cert_chain(ssl);
>
> +if (!cert_stack && (cert = SSL_get_peer_certificate(ssl))) {
> +/* client cert is in the session cache, but there is
> + * no chain, since ssl3_get_client_certificate()
> + * sk_X509_shift-ed the peer cert out of the chain.
> + * we put it back here for the purpose of quick_renegotiation.
> + */
> +cert_stack = sk_new_null();
> +sk_X509_push(cert_stack, cert);
> +}
> +
>if (!cert_stack || (sk_X509_num(cert_stack) == 0)) {
>ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
> "Cannot find peer certificate chain");
> @@ -745,6 +755,11 @@
>
>SSL_set_verify_result(ssl, cert_store_ctx.error);
>X509_STORE_CTX_cleanup(&cert_store_ctx);
> +
> +if (cert_stack != SSL_get_peer_cert_chain(ssl)) {
> +/* we created this ourselves, so free it */
> +sk_X509_pop_free(cert_stack, X509_free);
> +}
>}
>else {
>request_rec *id = r->main ? r->main : r;
>
>
>
> 1.819 +6 -0 httpd-2.0/CHANGES
>
> Index: CHANGES
> ===
> RCS file: /home/cvs/httpd-2.0/CHANGES,v
> retrieving revision 1.818
> retrieving revision 1.819
> diff -u -r1.818 -r1.819
> --- CHANGES 10 Jun 2002 18:51:37 - 1.818
> +++ CHANGES 11 Jun 2002 03:12:33 - 1.819
> @@ -1,5 +1,11 @@
>Changes with Apache 2.0.37
>
> + *) 'SSLOptions +OptRengotiate' will use client cert in from the ssl
> + session cache when there is no cert chain in the cache. prior to
> + the fix this situation would result in a FORBIDDEN response and
> + error message "Cannot find peer certificate chain"
> + [Doug MacEachern]
> +
> *) ap_finalize_sub_req_protocol() shouldn't send an EOS bucket if
> one was already sent. PR 9644 [Jeff Trawick]
>
>
>
>
>
Re: [PATCH] SSL, POST, and renegotiation
try with current cvs and 'SSLOptions +OptRenegotiate' configured. with this option enabled, modssl will use the client cert from the ssl session cache if one was not already sent by the client. in this case, modssl will not need to read from the client since full renegotiation is by-passed. this of course requires that you have SSLSessionCache of some sort enabled. and that your client either sends a cert automatically or is first requested to send one during a GET request, from which point the cert will be in the session cache when any POST happens afterwards. as for supporting POST where client cert is required on a per-location basis and OptRenegotiate is not enabled, i think any solution will be very painful to get right. when POST data is small, setting it aside in memory isn't so bad, but allowing large POSTs before the client has actually been authenticated leaves open potential DOS attacks. saving large POSTs to disk would likely result in more potential badness.
Re: cvs commit: httpd-2.0/modules/http http_protocol.c
On Fri, 31 May 2002, Justin Erenkrantz wrote: > httpd-test has no tests for input filtering. mod_input_body_filter.c at least, no? the protocol/ tests also hit input filters. > If I knew how to > get perl to send bogus requests, I would. But, my perl-fu is > severely lacking. -- justin see t/protocol/echo,nntp-like.t, you can send a request in any my $module = 'default'; #normally connects to port 8529 my $sock = Apache::TestRequest::vhost_socket($module); print $socket "SET \ ppp/2.2" ...
Re: httpd-2.0 STATUS
On Thu, 30 May 2002, William A. Rowe, Jr. wrote: > Perhaps we could resurrect the porting history [although I believe it's > horribly > incomplete] as modules/ssl/HISTORY? OTOH, those parts that are correct > aught to have been committed to CHANGES if they were not in the first place. they are in CHANGES, but it is HUGE. a summary is nice rather than having to sift through that file. the httpd CHANGES file is not very useful imho. too much info for users, to little for developers. i like what Perl and PHP do, Changes is generated from the perforce/cvs logs, has filenames, dates, submitter, committer, etc., handy for developers. then perldelta.pod contains a brief summary of the Changes that is useful and easy for users to understand. PHP has something similar, but calls it NEWS i think.
Re: httpd-2.0 STATUS
i see value the old modules/ssl/README. it has been very handy in the past, and i would expect it to be for anybody coming from mod_ssl 1.3 based sources to contribute to 2.0 or even just being brand new to the 2.0 source. now they have lost the source roadmap, summary of major changes, incompatibilities, etc. todo items being in modules/ssl or in the top-level STATUS, i don't really care. but why blow away the rest of the useful info that was in there?
Re: httpd-2.0 STATUS
On Thu, 30 May 2002, William A. Rowe, Jr. wrote: > is modules/ssl/README even valuable anymore? yes. fine to remove the stale stuff, but not the whole damn thing. there was a useful roadmap of the source in there and everything that was in the TODO section is still valid: o SSL renegotiations in combination with POST request o Port all remaining code (code inside #if 0...#endif blocks) o Do we need SSL_set_read_ahead()? o the ssl_expr api is NOT THREAD SAFE. race conditions exist: -in ssl_expr_comp() if SSLRequire is used in .htaccess (ssl_expr_info is global) -is ssl_expr_eval() if there is an error (ssl_expr_error is global) o SSLRequire directive (parsing of) leaks memory o Diffie-Hellman-Parameters for temporary keys are hardcoded in ssl_engine_dh.c, while the comment in ssl_engine_kernel.c says: "it is suggested that keys be changed daily or every 500 transactions, and more often if possible." o ssl_var_lookup could be rewritten to be MUCH faster o CRL callback should be pluggable o session cache store should be pluggable o init functions should return status code rather than ssl_die() o ssl_engine_pphrase.c needs to be reworked so it is generic enough to also decrypt proxy keys o the shmcb code should just align its memory segment rather than jumping through all the "safe" memcpy and memset hoops
ap_os_escape_pathn ?
ap_os_escape_path currently requires a pool argument to allocate the
string and does a strlen on it. wondering if we could do something like
the concept patch below, adding ap_os_escape_pathn which does not require
a pool and the path arg would be assumed to be allocated to the correct
size. would be a nice optimzation for perl land where string lengths are
always known and where the current ap_os_escape_path requires two copies,
the pool alloc and perl dup of the returned string. with something like
ap_os_escape_pathn we can avoid the strlen and the additional pool alloc.
could be useful elsewhere too i'm sure.
Index: server/util.c
===
RCS file: /home/cvs/httpd-2.0/server/util.c,v
retrieving revision 1.128
diff -u -r1.128 util.c
--- server/util.c 17 May 2002 11:11:37 - 1.128
+++ server/util.c 24 May 2002 16:33:40 -
@@ -1632,6 +1632,12 @@
AP_DECLARE(char *) ap_os_escape_path(apr_pool_t *p, const char *path, int partial)
{
char *copy = apr_palloc(p, 3 * strlen(path) + 3);
+return ap_os_escape_pathn(copy, partial);
+}
+
+AP_DECLARE(char *) ap_os_escape_pathn(char *copy, int partial)
+{
+char *path = copy;
const unsigned char *s = (const unsigned char *)path;
unsigned char *d = (unsigned char *)copy;
unsigned c;
Re: libexpat
On Wed, 22 May 2002, Greg Ames wrote: > Which release of httpd? 1.3 has a Configure rule to turn off expat. right. i'm asking about 2.0 (my original message specified)
Re: libexpat
On Tue, 21 May 2002, Greg Stein wrote: > Euh... we switched over to a shared library to specifically fix this > problem. Are you saying that that didn't work? I'm not buying it... :-) sooo, i guess the answer to my question on how to disable expat is "you can't" ? i haven't see the problem first hand, it was reported by a user who's running winnt, the server crashes using the XML::LibXML extension within modperl. might not be related to expat at all, but if there were a way to disable it, i would ask the user to try that first.
Re: libexpat
On Mon, 20 May 2002, William A. Rowe, Jr. wrote: > Context? httpd links in expat, perl extension links against a different version of expat. both have the same symbol names, and they are not binary compatible. perl extension resolves symbols to the httpd version. kaboom. its been an issue for years with 1.3, you'll find plenty in the modperl archives on it.
libexpat
how does one disable linking httpd against libexpat in 2.0? and on win32? i thought the nightmare was over where the expat linked with httpd cause segfaults with perl expat extensions. looks like i was wrong.
Re: Apache History Project - Call for comments
On Tue, 14 May 2002, Doug MacEachern wrote: > On Wed, 15 May 2002, Thomas Eibner wrote: > > > Full list of posters with more than 10 posts can be found at: > > http://stderr.net/history/topposters > > cool, now i am tied with ben hyde. haha, now i am 1 ahead of ben hyde, i'm #32 woohoo!
Re: Apache History Project - Call for comments
On Wed, 15 May 2002, Thomas Eibner wrote: > Full list of posters with more than 10 posts can be found at: > http://stderr.net/history/topposters cool, now i am tied with ben hyde.
Re: apache 2.0 trying to reinitialise ssl (fwd)
On Tue, 9 Apr 2002, Doug MacEachern wrote: > On Tue, 9 Apr 2002, Cliff Woolley wrote: > > it is possible jim is correct about the config issue, but it might also be > a bug in the static build (which i haven't tried in months) fyi - just ran httpd-test with a static build of mod_ssl, all tests pass.
Re: apache 2.0 trying to reinitialise ssl (fwd)
On Tue, 9 Apr 2002, Cliff Woolley wrote: it is possible jim is correct about the config issue, but it might also be a bug in the static build (which i haven't tried in months) > (i also tried configuring mod_ssl as a shared module, but then I had > problems with X509_INFO_free not being found) this is still an issue if the OpenSSL libraries are static (libssl.a and libcrypto.a, rather than .so), because the libraries are linked against httpd rather than mod_ssl.so why is it again that the ssl libraries get linked against httpd and not mod_ssl.so?
Re: Bug report for Apache httpd-2.0 [2002/04/07]
coupla dumb questions: - how do i get a login for the bugdb? - just fixed bug #7802, do i close it or mark as fixed and somebody else verifies and closes?
Re: Runaway SSL httpd server processes
i haven't been able to reproduce this, but the patch below (also in
cvs) may fix. seeing that ssl_io_hook_read sets rc = 0 if SSL_read
returns -1 and SSL_get_error is SSL_ERROR_WANT_READ. ssl_io_input_read
was *always* returning APR_SUCCESS if it got 0 bytes. now it only does so
if SSL_ERROR_WANT_READ was the reason, otherwise returns APR_EOF.
Index: modules/ssl/ssl_engine_io.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_io.c,v
retrieving revision 1.72
diff -u -r1.72 ssl_engine_io.c
--- modules/ssl/ssl_engine_io.c 5 Apr 2002 07:31:44 - 1.72
+++ modules/ssl/ssl_engine_io.c 7 Apr 2002 06:25:36 -
@@ -485,7 +485,7 @@
rc = SSL_read(ssl, buf, len);
-if (rc < 0) {
+if (rc <= 0) {
int ssl_err = SSL_get_error(ssl, rc);
if (ssl_err == SSL_ERROR_WANT_READ) {
@@ -673,6 +673,10 @@
if (ctx->inbio.mode == AP_MODE_SPECULATIVE) {
char_buffer_write(&ctx->cbuf, buf, rc);
}
+}
+else if ((rc == 0) && (errno != EINTR)) {
+/* something other than SSL_ERROR_WANT_READ */
+return APR_EOF;
}
else if ((rc == -1) && (ctx->inbio.rc == APR_SUCCESS)) {
/*
[announce] mod_perl-1.99_01
The URL http://perl.apache.org/dist/mod_perl-1.99_01.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.99_01.tar.gz size: 368151 bytes md5: 8db81a4cc572544eb427f2beb1beceea This is the first public release of mod_perl version 2.0-tobe. Apache version 2.0.35 or higher is required. Perl version 5.6.0 or higher is required. mod_perl is currently considered beta when used with the prefork MPM. mod_perl is currently considered alpha when used with a threaded MPM. Only DSO build of mod_perl-2.0 is currently supported, static builds will be support in the future. mod_perl-2.0-tobe is not 100% feature complete with the 1.xx version. See the todo/ directory for what remains to be done. Comments, questions, bug-reports, etc., should be sent to the mod_perl users list: [EMAIL PROTECTED] Enjoy, -Doug
Re: Difficulties with SSL and mod_proxy
argh. i tested http <-> https and https <-> https, but never
https <-> http. it is indeed broken, although i don't see how it ever
could have worked, unless mod_proxy was somehow removing the ssl filter by
accident (which it had been at one point during keepalives after the first
request).
problem is that the mod_ssl always adds its filters if SSLEngine is On for
the given c->base_server. it has no way of knowing that it is being
triggered by the proxy. one fix (patch below) is to add another optional
function to disable the ssl engine for a given conn_rec at request time.
proxy imports this function and calls it to disable the ssl filters unless
the backend server requires an ssl connection.
Index: modules/proxy/mod_proxy.c
===
RCS file: /home/cvs/httpd-2.0/modules/proxy/mod_proxy.c,v
retrieving revision 1.79
diff -u -r1.79 mod_proxy.c
--- modules/proxy/mod_proxy.c 1 Apr 2002 02:39:31 - 1.79
+++ modules/proxy/mod_proxy.c 7 Apr 2002 02:24:37 -
@@ -1048,8 +1048,10 @@
};
APR_DECLARE_OPTIONAL_FN(int, ssl_proxy_enable, (conn_rec *));
+APR_DECLARE_OPTIONAL_FN(int, ssl_engine_disable, (conn_rec *));
static APR_OPTIONAL_FN_TYPE(ssl_proxy_enable) *proxy_ssl_enable = NULL;
+static APR_OPTIONAL_FN_TYPE(ssl_engine_disable) *proxy_ssl_disable = NULL;
PROXY_DECLARE(int) ap_proxy_ssl_enable(conn_rec *c)
{
@@ -1064,10 +1066,20 @@
return 0;
}
+PROXY_DECLARE(int) ap_proxy_ssl_disable(conn_rec *c)
+{
+if (proxy_ssl_disable) {
+return proxy_ssl_disable(c);
+}
+
+return 0;
+}
+
static int proxy_post_config(apr_pool_t *pconf, apr_pool_t *plog,
apr_pool_t *ptemp, server_rec *s)
{
proxy_ssl_enable = APR_RETRIEVE_OPTIONAL_FN(ssl_proxy_enable);
+proxy_ssl_disable = APR_RETRIEVE_OPTIONAL_FN(ssl_engine_disable);
return OK;
}
Index: modules/proxy/mod_proxy.h
===
RCS file: /home/cvs/httpd-2.0/modules/proxy/mod_proxy.h,v
retrieving revision 1.78
diff -u -r1.78 mod_proxy.h
--- modules/proxy/mod_proxy.h 2 Apr 2002 04:30:49 - 1.78
+++ modules/proxy/mod_proxy.h 7 Apr 2002 02:24:37 -
@@ -274,5 +274,6 @@
PROXY_DECLARE(void) ap_proxy_table_unmerge(apr_pool_t *p, apr_table_t *t, char *key);
PROXY_DECLARE(int) ap_proxy_connect_to_backend(apr_socket_t **, const char *,
apr_sockaddr_t *, const char *, proxy_server_conf *, server_rec *, apr_pool_t *);
PROXY_DECLARE(int) ap_proxy_ssl_enable(conn_rec *c);
+PROXY_DECLARE(int) ap_proxy_ssl_disable(conn_rec *c);
#endif /*MOD_PROXY_H*/
Index: modules/proxy/proxy_http.c
===
RCS file: /home/cvs/httpd-2.0/modules/proxy/proxy_http.c,v
retrieving revision 1.144
diff -u -r1.144 proxy_http.c
--- modules/proxy/proxy_http.c 5 Apr 2002 18:08:07 - 1.144
+++ modules/proxy/proxy_http.c 7 Apr 2002 02:24:38 -
@@ -389,11 +389,16 @@
backend->hostname = apr_pstrdup(c->pool, p_conn->name);
backend->port = p_conn->port;
-if (backend->is_ssl && !ap_proxy_ssl_enable(backend->connection)) {
-ap_log_error(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO, 0,
- r->server, "proxy: failed to enable ssl support "
- "for %pI (%s)", p_conn->addr, p_conn->name);
-return HTTP_INTERNAL_SERVER_ERROR;
+if (backend->is_ssl) {
+if (!ap_proxy_ssl_enable(backend->connection)) {
+ap_log_error(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO, 0,
+ r->server, "proxy: failed to enable ssl support "
+ "for %pI (%s)", p_conn->addr, p_conn->name);
+return HTTP_INTERNAL_SERVER_ERROR;
+}
+}
+else {
+ap_proxy_ssl_disable(backend->connection);
}
ap_log_error(APLOG_MARK, APLOG_DEBUG|APLOG_NOERRNO, 0, r->server,
Index: modules/ssl/mod_ssl.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/mod_ssl.c,v
retrieving revision 1.62
diff -u -r1.62 mod_ssl.c
--- modules/ssl/mod_ssl.c 2 Apr 2002 17:30:08 - 1.62
+++ modules/ssl/mod_ssl.c 7 Apr 2002 02:24:38 -
@@ -252,6 +252,24 @@
}
sslconn->is_proxy = 1;
+sslconn->disabled = 0;
+
+return 1;
+}
+
+int ssl_engine_disable(conn_rec *c)
+{
+SSLSrvConfigRec *sc = mySrvConfig(c->base_server);
+
+SSLConnRec *sslconn;
+
+if (!sc->enabled) {
+return FALSE;
+}
+
+sslconn = ssl_init_connection_ctx(c);
+
+sslconn->disabled = 1;
return 1;
}
@@ -279,6 +297,10 @@
sslconn = ssl_init_connection_ctx(c);
}
+if (sslconn->disabled) {
+return DECLINED;
+}
+
sslconn->log_level = sc->log_level;
/*
@@ -560,6 +582,7 @@
ssl_var_register();
APR_REGISTER_OPTION
RE: I WANT A GA release
+1 on GA. 2 issues on HEAD i'd like to see resolved first: - proxy not sending content-length - httpd.conf not installed with vpath builds (issue does not exist with current .34 tag)
RE: proxy not sending Content-Length
On Thu, 4 Apr 2002, Ryan Bloom wrote: > The proxy should flush, because otherwise the data won't stream to the > client. doesn't the core flush once it has max-something bytes or eos? > The problem that I see, is that the proxy shouldn't be removing > the C-L from the response that the origin server provided. other filters may have modified the content, so it is possible content length could end up different from what the downstream server sent.
proxy not sending Content-Length
mod_proxy does not send a Content-Length header, seems because of the
flush bucket inserted by ap_proxy_http_process_response()
if i break in ap_content_length_filter, when a request is handled by
default_handler, brigade looks like so:
(gdb) dump_brigade b
dump of brigade 0x8235318
0: bucket=FILE(0x8238c28), length=26, data=0x8238c78
1: bucket=EOS(0x822e998), length=0, data=0x0
here's what it currently looks like when handled by the proxy:
(gdb) dump_brigade b
dump of brigade 0x82310a8
0: bucket=HEAP(0x822e998), length=26, data=0x8238c28
1: bucket=FLUSH(0x8218ea8), length=0, data=0x0
(gdb) dump_brigade b
dump of brigade 0x82310a8
0: bucket=EOS(0x8238c28), length=0, data=0x0
if i remove the flush bucket (patch below), then proxy requests do get a
Content-Length header. doesn't seem like proxy should be flushing to
begin with. thoughts?
Index: modules/proxy/proxy_http.c
===
RCS file: /home/cvs/httpd-2.0/modules/proxy/proxy_http.c,v
retrieving revision 1.143
diff -u -r1.143 proxy_http.c
--- modules/proxy/proxy_http.c 2 Apr 2002 04:30:49 - 1.143
+++ modules/proxy/proxy_http.c 5 Apr 2002 04:17:09 -
@@ -841,7 +841,6 @@
if ( (conf->error_override ==0) || r->status < 400 ) {
/* read the body, pass it to the output filters */
-apr_bucket *e;
int finish = FALSE;
while (ap_get_brigade(rp->input_filters,
bb,
@@ -873,12 +872,6 @@
ap_proxy_http_cleanup(r, p_conn, backend);
/* signal that we must leave */
finish = TRUE;
-}
-
-/* if no EOS yet, then we must flush */
-if (FALSE == finish) {
-e = apr_bucket_flush_create(c->bucket_alloc);
-APR_BRIGADE_INSERT_TAIL(bb, e);
}
/* try send what we read */
cvs commit: httpd-2.0/modules/ssl ssl_engine_kernel.c (fwd)
dear RM, please consider bumping for .34, else users with the typical ssl
proxy config:
SSLProxyEngine On
ProxyPass/ https://foo/
ProxyPassReverse / https://foo/
will get this ugly error message on every request:
[error] mod_ssl: Certificate Verification: Error ...
even though when SSLProxyVerify is not configured it defaults to "none".
in the server context we never see this because the callback never happens
unless SSLVerifyClient is configured to something other than "none".
the 1.3 based mod_ssl:ssl_engine_ext.c:ssl_ext_mp_verify_cb does the equiv
of the patch here:
/*
* Unless stated otherwise by the configuration, we really don't
* care if the verification was okay or not, so lets return now
* before we do anything involving memory or time.
*/
if (sc->bProxyVerify == FALSE)
return ok;
-- Forwarded message --
Date: 5 Apr 2002 02:31:04 -
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: cvs commit: httpd-2.0/modules/ssl ssl_engine_kernel.c
dougm 02/04/04 18:31:04
Modified:modules/ssl ssl_engine_kernel.c
Log:
avoid the error_log message: [error] mod_ssl: Certificate Verification: Error ...
if SSLProxyVerify is not configured or set to "none".
the verify callback does not happen in the server context when
SSLVerify is not configured or set to "none".
Revision ChangesPath
1.67 +9 -0 httpd-2.0/modules/ssl/ssl_engine_kernel.c
Index: ssl_engine_kernel.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_kernel.c,v
retrieving revision 1.66
retrieving revision 1.67
diff -u -r1.66 -r1.67
--- ssl_engine_kernel.c 30 Mar 2002 08:11:44 - 1.66
+++ ssl_engine_kernel.c 5 Apr 2002 02:31:04 - 1.67
@@ -1305,6 +1305,15 @@
verify = mctx->auth.verify_mode;
}
+if (verify == SSL_CVERIFY_NONE) {
+/*
+ * SSLProxyVerify is either not configured or set to "none".
+ * (this callback doesn't happen in the server context if SSLVerify
+ * is not configured or set to "none")
+ */
+return TRUE;
+}
+
if (ssl_verify_error_is_optional(errnum) &&
(verify == SSL_CVERIFY_OPTIONAL_NO_CA))
{
Re: httpd.conf no longer installed
On Thu, 4 Apr 2002, Pier Fumagalli wrote: > What do your last lines of configure.in look like? And when you run > "./configure. " what's the output of the last (let's say) 50 lines? mkdir: cannot create directory `docs/conf': No such file or directory creating docs/conf/httpd-std.conf ./config.status: docs/conf/httpd-std.conf: No such file or directory problem is likely related to VPATH builds. the build tree does not have a docs/ directory: % ls build/config.nice*Makefile os/ support/ config.cache config.status* modules/ server/ config.loginclude/modules.c srclib/
Re: httpd.conf no longer installed
nope, still isn't there. % uname -a Linux mako.covalent.net 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown % autoconf --version Autoconf version 2.13 % cat config.nice #! /bin/sh # # Created by configure CFLAGS="-Wall -g"; export CFLAGS "/home/dougm/apache/farm/src/httpd-2.0-cvs/configure" \ "--prefix=/home/dougm/apache/farm/install/prefork-debug-shared-all-exp" \ "--with-mpm=prefork" \ "--srcdir=/home/dougm/apache/farm/src/httpd-2.0-cvs" \ "--enable-maintainer-mode" \ "--enable-mods-shared=all" \ "--enable-modules=all" \ "--enable-example" \ "--enable-case_filter" \ "--enable-case_filter_in" \ "--enable-cache" \ "--enable-echo" \ "--enable-deflate" \ "--enable-ssl" \ "--with-ssl=/home/dougm/openssl" \ "$@"
Re: httpd.conf no longer installed
On Thu, 4 Apr 2002, Pier Fumagalli wrote: > Did you run ./buildconf? yup, always. i probably just need blow away my cvs tree and start from scratch. has cured similar trouble in the past. i'll report back if the problem is still there.
httpd.conf no longer installed
with httpd-2.0-HEAD, installing into a directory where no conf/ already exists, no httpd.conf is installed, only: % ls -1 conf/ highperformance.conf highperformance-std.conf httpd.conf.in httpd-std.conf.in magic mime.types ssl.conf ssl-std.conf problem does not exist with the APACHE_2_0_34 tag.
Re: fix t/ssl/http.t
On Wed, 3 Apr 2002, Cliff Woolley wrote: > Only one other thing I'm concerned about with it: It's only correct if > we're in AP_MODE_GETLINE at the time of the error. Which we are in this > case, but will it always be that way? i think so, assuming AP_MODE_GETLINE always happens first. on the first call SSL_R_HTTP_REQUEST is detected and ssl filters are disabled. so any get_brigade calls after that with same or different mode will happen with ssl filters disabled.
Re: fix t/ssl/http.t
On Wed, 3 Apr 2002, Cliff Woolley wrote: > On Tue, 2 Apr 2002, Doug MacEachern wrote: > > > apr_bucket_immortal_create(HTTP_ON_HTTPS_PORT, \ > > - sizeof(HTTP_ON_HTTPS_PORT) - 1, \ > > + sizeof(HTTP_ON_HTTPS_PORT), \ > > Mmmm... no. I don't know how that makes it work its way through, but it's > not right. That null character should never be allowed in. like i said, "this is strange", never suggested the patch was correct. > The correct solution is this: cool, +1
Re: fix t/ssl/http.t
this is not quite fixed. currently does return 400 Bad Request, but reports: "Your browser sent a request that this server could not understand. Request header field is missing colon separator." with the patch below it properly reports: "Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please. Hint: https://localhost:8530/"; this is strange. --- modules/ssl/ssl_engine_io.c 2 Apr 2002 17:30:08 - 1.71 +++ modules/ssl/ssl_engine_io.c 3 Apr 2002 04:19:23 - @@ -740,7 +740,7 @@ #define HTTP_ON_HTTPS_PORT_BUCKET(alloc) \ apr_bucket_immortal_create(HTTP_ON_HTTPS_PORT, \ - sizeof(HTTP_ON_HTTPS_PORT) - 1, \ + sizeof(HTTP_ON_HTTPS_PORT), \ alloc) static void ssl_io_filter_disable(ap_filter_t *f)
ssl proxy fixes for .34
if the following tags in modules/ssl could be pushed: /ssl_engine_config.c/1.66/Tue Apr 2 21:49:09 2002// /ssl_engine_init.c/1.94/Tue Apr 2 21:46:22 2002// /ssl_util_ssl.c/1.20/Tue Apr 2 22:04:16 2002// minor fixes to get SSLProxyMachineCertificatePath working.
RE: fix t/ssl/http.t
On Tue, 2 Apr 2002, Ryan Bloom wrote: > Nope, I fixed this. The problem was that we couldn't remove the first > filter in any of the three lists, because the previous filter structure > wouldn't be updated. The solution was to walk the filter list each time > we tried to remove a filter. This allows us to find the correct filter > entry and set the pointers appropriately. there is still a problem. ssl is removed from c->output_filters, but not r->output_filters. mod_ssl does not have access to r->output_filters.
RE: fix t/ssl/http.t
On Tue, 2 Apr 2002, Ryan Bloom wrote: > It is perfectly possible for a filter to remove itself. In fact, the > byterange filter relies on that ability to work correctly. While I > would be interested to know what happened to make that case fail, if the > patch below works, then +1. i was thinking of this comment from justin: Date: Thu, 7 Mar 2002 01:42:27 -0800 From: Justin Erenkrantz <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: httpd-test + cvs head Message-ID: <[EMAIL PROTECTED]> ... However, mod_ssl is bogus. The ssl/http.t test is interesting since it causes mod_ssl to remove itself via ap_remove_output_filter() (mod_ssl.c:358). Since mod_ssl is a connection filter, our new strategy is that it can never be removed. Ooops. Since it doesn't have access to the request_rec, it can't destroy its predecessor's reference to itself. Perhaps this means we *do* need the ->prev. ... is this still true? (note: mod_ssl.c:358 is now 421)
fix t/ssl/http.t
the test started failing at some point due to filter changes. i think i
heard it is not longer possible for a filter to remove itself? in any
case, mod_ssl already checks in the output filter already passes if its
ssl pointer is NULL (normally due to error). the input filter should
probably do the same too. and with that it is simple to disable the ssl
filters in the case of 'HTTP spoken on HTTPS port'
if there's a better way, that'd be great, but the patch below passes all
httpd-tests for me.
Index: modules/ssl/ssl_engine_io.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_io.c,v
retrieving revision 1.70
diff -u -r1.70 ssl_engine_io.c
--- modules/ssl/ssl_engine_io.c 30 Mar 2002 05:16:55 - 1.70
+++ modules/ssl/ssl_engine_io.c 2 Apr 2002 16:05:32 -
@@ -743,6 +743,13 @@
sizeof(HTTP_ON_HTTPS_PORT) - 1, \
alloc)
+static void ssl_io_filter_disable(ap_filter_t *f)
+{
+ssl_io_input_ctx_t *ctx = f->ctx;
+ctx->inbio.ssl = NULL;
+ctx->frec->pssl = NULL;
+}
+
static apr_status_t ssl_io_filter_error(ap_filter_t *f,
apr_bucket_brigade *bb,
apr_status_t status)
@@ -758,6 +765,7 @@
/* fake the request line */
bucket = HTTP_ON_HTTPS_PORT_BUCKET(f->c->bucket_alloc);
+ssl_io_filter_disable(f);
break;
default:
@@ -780,6 +788,10 @@
apr_size_t len = sizeof(ctx->buffer);
int is_init = (mode == AP_MODE_INIT);
+
+if (!ctx->inbio.ssl) {
+return ap_get_brigade(f->next, bb, mode, block, readbytes);
+}
/* XXX: we don't currently support anything other than these modes. */
if (mode != AP_MODE_READBYTES && mode != AP_MODE_GETLINE &&
Re: Bump a few more tags. :-)
On Mon, 1 Apr 2002, William A. Rowe, Jr. wrote: > Sounds like that could be Doug's latest changes he asked to incorporate. > > Doug, was there an additional file to bump, beyond the three you cited? nope. sounds specific to perchild, cliff does the proxy test pass for you with prefork and/or worker? i can take a look in the morning.
Re: bio_bucket_in_read bug [was Re: Bump a few more tags. :-)]
your grep pattern missed this one: ctx->inbio.block = block;
cvs commit: httpd-2.0/modules/proxy mod_proxy.h proxy_http.cproxy_util.c (fwd)
RM can you bump the .34 tag on these files? thanks.
-- Forwarded message --
Date: 2 Apr 2002 04:30:49 -
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: cvs commit: httpd-2.0/modules/proxy mod_proxy.h proxy_http.c
proxy_util.c
dougm 02/04/01 20:30:49
Modified:modules/proxy mod_proxy.h proxy_http.c proxy_util.c
Log:
Reviewed by: Ryan Bloom
remove call to ap_proxy_reset_output_filters() and the function itself.
this call breaks ssl proxy when the client is using keepalives.
this function is also no longer needed with recent-ish filter changes.
Revision ChangesPath
1.78 +0 -1 httpd-2.0/modules/proxy/mod_proxy.h
Index: mod_proxy.h
===
RCS file: /home/cvs/httpd-2.0/modules/proxy/mod_proxy.h,v
retrieving revision 1.77
retrieving revision 1.78
diff -u -r1.77 -r1.78
--- mod_proxy.h 29 Mar 2002 07:29:11 - 1.77
+++ mod_proxy.h 2 Apr 2002 04:30:49 - 1.78
@@ -271,7 +271,6 @@
PROXY_DECLARE(int) ap_proxy_checkproxyblock(request_rec *r, proxy_server_conf
*conf, apr_sockaddr_t *uri_addr);
PROXY_DECLARE(int) ap_proxy_pre_http_request(conn_rec *c, request_rec *r);
PROXY_DECLARE(apr_status_t) ap_proxy_string_read(conn_rec *c, apr_bucket_brigade
*bb, char *buff, size_t bufflen, int *eos);
-PROXY_DECLARE(void) ap_proxy_reset_output_filters(conn_rec *c);
PROXY_DECLARE(void) ap_proxy_table_unmerge(apr_pool_t *p, apr_table_t *t, char
*key);
PROXY_DECLARE(int) ap_proxy_connect_to_backend(apr_socket_t **, const char *,
apr_sockaddr_t *, const char *, proxy_server_conf *, server_rec *, apr_pool_t *);
PROXY_DECLARE(int) ap_proxy_ssl_enable(conn_rec *c);
1.143 +0 -3 httpd-2.0/modules/proxy/proxy_http.c
Index: proxy_http.c
===
RCS file: /home/cvs/httpd-2.0/modules/proxy/proxy_http.c,v
retrieving revision 1.142
retrieving revision 1.143
diff -u -r1.142 -r1.143
--- proxy_http.c 30 Mar 2002 06:19:14 - 1.142
+++ proxy_http.c 2 Apr 2002 04:30:49 - 1.143
@@ -326,9 +326,6 @@
p_conn->sock = client_socket;
new = 0;
-/* reset the connection filters */
-ap_proxy_reset_output_filters(*origin);
-
/* save timeout */
apr_getsocketopt(p_conn->sock, APR_SO_TIMEOUT, ¤t_timeout);
/* set no timeout */
1.88 +0 -19 httpd-2.0/modules/proxy/proxy_util.c
Index: proxy_util.c
===
RCS file: /home/cvs/httpd-2.0/modules/proxy/proxy_util.c,v
retrieving revision 1.87
retrieving revision 1.88
diff -u -r1.87 -r1.88
--- proxy_util.c 22 Mar 2002 21:41:14 - 1.87
+++ proxy_util.c 2 Apr 2002 04:30:49 - 1.88
@@ -1062,25 +1062,6 @@
return APR_SUCCESS;
}
-/* remove other filters (like DECHUNK) from filter stack */
-PROXY_DECLARE(void) ap_proxy_reset_output_filters(conn_rec *c)
-{
-ap_filter_t *f = c->output_filters;
-
-while (f) {
-if (!strcasecmp(f->frec->name, "CORE") ||
-!strcasecmp(f->frec->name, "CONTENT_LENGTH") ||
-!strcasecmp(f->frec->name, "HTTP_HEADER")) {
-f = f->next;
-continue;
-}
-else {
-ap_remove_output_filter(f);
-f = f->next;
-}
-}
-}
-
/* unmerge an element in the table */
PROXY_DECLARE(void) ap_proxy_table_unmerge(apr_pool_t *p, apr_table_t *t, char *key)
{
Re: cvs commit: httpd-2.0 CHANGES
On Sun, 31 Mar 2002, Brian Pane wrote: > Should that be in the 2.0.34 section, or the 2.0.35 one? wrowe has moved HEAD to the 2.0.34 tag, which includes the ssl proxy changes.
Re: bucket free list breakage (was Re: cvs commit:httpd-2.0/server/mpm/workerworker.c)
On Fri, 29 Mar 2002, Cliff Woolley wrote: > Yes. The SSLProxyEngine on directive is missing from the config file. I > added it manually and it works. I expect something like this would do the > trick: oh duh, i had made the change but didn't commit. glad to hear it works.
Re: bucket free list breakage (was Re: cvs commit:httpd-2.0/server/mpm/workerworker.c)
On Fri, 29 Mar 2002, Cliff Woolley wrote: > Okay, fixed. excellent, thanks. > PS: I now pass all httpd-test tests except these: http.t fails for me too, has for a while. proxy.t passes for me, but this is new stuff. anything interesting in the error_log?
Re: bucket free list breakage (was Re: cvs commit: httpd-2.0/server/mpm/workerworker.c)
On Fri, 29 Mar 2002, Brian Pane wrote:
> Does the rest of *h look valid? (That could help us differentiate memory
> corruption from some code path that just forgot to set h->free_func.)
(gdb) p *h
$1 = {refcount = {refcount = 0},
base = 0x824f568 "mod_include test(\026/@\021", alloc_len = 16,
free_func = 0}
(gdb) p h
$2 = (apr_bucket_heap *) 0x824f5f0
i checked in a test early this morning that triggers the bug,
t/modules/include2.t
t/php/virtual.t also has the same problem.
bucket free list breakage (was Re: cvs commit: httpd-2.0/server/mpm/workerworker.c)
just looked a bit more, the problem is related to heap buckets and the free functions. something is broken for sure. i could probably bandaid, but cliff if you take a look, i'm assuming the right fix would be obvious to you. #1 0x4001cf76 in heap_destroy (data=0x824f758) at /home/dougm/apache/farm/src/httpd-2.0-cvs/srclib/apr-util/buckets/apr_buckets_heap.c:74 74 (*h->free_func)(h->base); (gdb) p f->free_func No symbol "f" in current context. (gdb) p h->free_func $1 = (void (*)()) 0
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
On Fri, 29 Mar 2002, Cliff Woolley wrote: > On Fri, 29 Mar 2002, Doug MacEachern wrote: > > > fyi: t/php/virtual produces the same stacktrace > > I'll look into this this afternoon. great. probably easier to work with t/modules/include2.t, stacktrace looks like they suffer the same problem. > Has PHP really been updated for the new buckets API already?? yup and modperl-2.0 too.
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
On Fri, 29 Mar 2002, Doug MacEachern wrote: > not sure if this is related to the bucket list change or mod_includes > changes or what, but i just checked in a test adapted from modperl that > dumps core. stacktrace below from t/TEST t/modules/include2.t fyi: t/php/virtual produces the same stacktrace i have php checked out like so: % cvs -d ... co -rphp_4_1_2 php4 % cd php4 % cvs co -rphp_4_1_2 Zend TSRM % cd sapi/apache2filter % cvs up -A *.[ch] % cd ../../.. % ./buildconf && ./configure --with-apxs2=... && make
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
On Fri, 29 Mar 2002, Doug MacEachern wrote: > another problem after fixing the httpd-test c-modules to compile: > t/apache/passbrigade eats all cpu. have not looked into it. nevermind. i didn't notice the modules had been updated and my cvs commit up-to-date check failed. this test is working fine for me now.
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
another problem after fixing the httpd-test c-modules to compile: t/apache/passbrigade eats all cpu. have not looked into it.
Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
not sure if this is related to the bucket list change or mod_includes changes or what, but i just checked in a test adapted from modperl that dumps core. stacktrace below from t/TEST t/modules/include2.t #0 0x0815a897 in ?? () at eval.c:41 41 eval.c: No such file or directory. in eval.c #1 0x4001dbe3 in apr_brigade_cleanup (data=0x81c77a0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/srclib/apr-util/buckets/apr_brigade.c:86 #2 0x4001dc3c in apr_brigade_destroy (b=0x81c77a0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/srclib/apr-util/buckets/apr_brigade.c:97 #3 0x0807f731 in core_output_filter (f=0x81c7548, b=0x81c77a0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/core.c:3758 #4 0x08075bc0 in ap_pass_brigade (next=0x81c7548, bb=0x81cc418) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:534 #5 0x08063bce in ap_http_header_filter (f=0x81cfb40, b=0x81cc418) at /home/dougm/apache/farm/src/httpd-2.0-cvs/modules/http/http_protocol.c:1472 #6 0x08075bc0 in ap_pass_brigade (next=0x81cfb40, bb=0x81cc418) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:534 #7 0x08078a0a in ap_content_length_filter (f=0x81cfb28, b=0x81cc418) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/protocol.c:1263 #8 0x08075bc0 in ap_pass_brigade (next=0x81cfb28, bb=0x81cc498) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:534 #9 0x4031692f in send_parsed_content (bb=0xb344, r=0x81cf1c0, f=0x81cbad8) at /home/dougm/apache/farm/src/httpd-2.0-cvs/modules/filters/mod_include.c:3186 #11 0x08075bc0 in ap_pass_brigade (next=0x81cbad8, bb=0x81cbbf0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:534 #12 0x0807e723 in default_handler (r=0x81cf1c0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/core.c:3247 #13 0x0806950f in ap_run_handler (r=0x81cf1c0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/config.c:193 #14 0x08069b8d in ap_invoke_handler (r=0x81cf1c0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/config.c:373 #15 0x080665dd in ap_process_request (r=0x81cf1c0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/modules/http/http_request.c:261 #16 0x08061355 in ap_process_http_connection (c=0x81c7270) at /home/dougm/apache/farm/src/httpd-2.0-cvs/modules/http/http_core.c:291 #17 0x0807379b in ap_run_process_connection (c=0x81c7270) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/connection.c:85 #18 0x08073b42 in ap_process_connection (c=0x81c7270, csd=0x81c71a0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/connection.c:207 #19 0x08067d6f in child_main (child_num_arg=0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/mpm/prefork/prefork.c:675 #20 0x08067ef8 in make_child (s=0x80a5f10, slot=0) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/mpm/prefork/prefork.c:770 #21 0x08067f6d in startup_children (number_to_start=1) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/mpm/prefork/prefork.c:793 #22 0x080683a0 in ap_mpm_run (_pconf=0x80a41c0, plog=0x80ce268, s=0x80a5f10) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/mpm/prefork/prefork.c:1016 #23 0x0806e644 in main (argc=6, argv=0xb654) at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/main.c:618 #24 0x401d9507 in __libc_start_main (main=0x806de50 , argc=6, ubp_av=0xb654, init=0x805eb14 <_init>, fini=0x808cd10 <_fini>, rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xb64c) at ../sysdeps/generic/libc-start.c:129
Re: cvs commit: httpd-2.0/modules/ssl ssl_engine_init.c
On Wed, 27 Mar 2002, Greg Stein wrote: > Maybe this could return a status, rather than just calling ssl_die()? (and > have the caller do the die...) > > Personally, I'd rather see an eventual case where you bubble up the death, > and let Apache core do the exiting, rather than having the module just go > bell-up. Adding return codes where possible can help to move towards that > long term goal. planning on that and getting rid of ssl_die() everywhere. i'll be making a few passes during this reorg, all these new functions are going to tweaked a few more times. main focus is supporting proxy, but will be cleaning up things like this along the way.
RE: [PATCH] SSL Session Caching stuff
On Thu, 14 Mar 2002, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> if (Pass-1) {
...
> }
> else if (Pass-2) {
i don't know how to fix it, but we should't assume anything based pass-1,
pass-2, etc. otherwise it isn't possible to add mod_ssl to a server that
was started without it, consider:
1) apachectl start (no mod_ssl in httpd.conf)
2) add mod_ssl to httpd.conf and configure SSLSharedCache
3) apachectl graceful
the session cache will never be initialized.
and consider re-configuring the session cache parameters and then doing a
graceful restart. ok if it's just a temporary workaround though.
Re: [PATCH] SSL Session Caching stuff
looks good to me madhu. haven't tested, but it compiles, so i've
committed the patch and remaining issues can be worked out later.
only have one question at the moment, what is this for?
+void *data;
+const char *userdata_key = "ssl_scache_init";
+
+apr_pool_userdata_get(&data, userdata_key, s->process->pool);
+if (!data) {
+apr_pool_userdata_setn((const void *)1, userdata_key,
+ apr_pool_cleanup_null, s->process->pool);
+return;
+}
Re: putting mod_scoreboard_send in core?
a few notes on this.. the purpose of mod_scoreboard_send was to "download" the scoreboard image on a remote machine. the scoreboard image was then used on the client machine to generate fancy graphical images to make our boss feel like he knew what was going on. sorta like a graphical mod_status, but could also combine stats of a server farm into one browser window. anyhoo, the module should not go in as-is, it was designed to incur as little overhead as possible, pretty much sends the binary data as-is. and hence isn't portable since it uses native byte order rather than network order. which was ok for us since the client machine was the same architecture as the servers. and the concept might not apply at all to the 2.0 scoreboard, i haven't looked at it. in general, the concept is to serialize the scoreboard in such a way that it can transfered over the network via http and "thawed" on another machine. i'm sure there's a better way to do this than the mod_scoreboard_send thinger.
Re: [PATCH] ssl_engine_vars.c
On Wed, 13 Mar 2002, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > 'just did a cvs update and found that SSL_SESSION_id2sz in ssl_engine_vars.c > has fewer parameters than required. whoops, my bad. thanks, applied.
Re: [BUG] Limit test 10 is failing
On Tue, 12 Mar 2002, Sander Striker wrote: > #User-Agent: libwww-perl/5.53 could be a bug in the client. try 5.64 you can also grab: http://httpd.apache.org/~dougm/httpd-test-bundle-0.02.tar.gz unpack and run: % echo | perl Makefile.PL && make install (the 'echo |' trick makes all prompts use the default) ignore warnings about prerequisites, they are probably complaining missing modules which are about to be installed.
mod_ssl surgery for proxy extensions
i'm working on implementing the proxy extensions for mod_ssl in 2.0.
the 1.3 based implementation duplicates a bunch of code, for example
the directives:
SSLProxyProtocol - same as SSLProtocol
SSLProxyCipherSuite - same as SSLCipherSuite
SSLProxyVerify - same as SSLVerifyClient
SSLProxyVerifyDepth - same as SSLVerifyDepth
SSLProxyCACertificateFile - same as SSLCACertificateFile
SSLProxyCACertificatePath - same as SSLCACertificatePath
SSLProxyMachineCertificateFile
SSLProxyMachineCertificatePath - similar to SSLCertificateFile and
SSLCertificateKeyFile
ssl_ext_mp_init() duplicates much of ssl_init_Module:
- configuring verify
- configuring ssl protocol
- creating an SSL_CTX (though somewhat different, proxy needs to use
*_client_method(), server needs to use *_server_method())
- configuring CA Certificates
- configuring cipher suite
- setting session cache callbacks
- etc.
ssl_engine_ext.c:ssl_ext_mp_verify_cb and
ssl_engine_kernel.c:ssl_callback_SSLVerify are nearly identical
functionality wise.
the way i see it, most of this duplication can be folded, with a few
conditionals depending on being a client (the proxy) or server.
and this is pretty much a requirement if the ssl proxy is to use the
existing ssl filters.
required changes would start with splitting up SSLSrvConfigRec. i've
included a prototype below. moves most of the structure into a
"context" structure and what remains of the old SSLSrvConfigRec is log
file, log level, etc. the new "context" structure can be used for
both the server and client (proxy). the server config structure now
has two of these "context" structures, one for the server and one for
the proxy client.
i've taken the liberty of dropping hungarian notation in the process.
from there, existing functions would need to be adjusted to the new
structure(s). then existing functions made generic to work with both a
server and client (proxy) context, which would be a few conditionals.
the main differences would then be the certs/keys, for which the
server has 1-2 configured at startup (SSL_CTX_use_{PrivateKey,certificate)
and the proxy has any number selected at request time with a client
specific callback (SSL_CTX_set_client_cert_cb). another tricky part
would supporting encrypted keys for proxy client certs, which the 1.3
based module currently does not. but that would be a different
project for a rainy day. in the end if all goes as planned, once the
mod_ssl core has been re-arranged to be more generic, ssl_engine_ext.c
would shrink next to nothing and mod_proxy would call 1 optional
function to support ssl. the SSLProxy* directives would still exist,
but would be using the same functions as the SSL* directives in most
cases. thoughts?
typedef enum {
/* we can be a client or a server */
SSL_METHOD_TYPE_CLIENT,
SSL_METHOD_TYPE_SERVER
} ssl_method_type_e;
typedef struct {
/*
* server only has 1-2 certs/keys
* 1 RSA and/or 1 DSA
*/
const char *public_cert_file[SSL_AIDX_MAX];
const char *private_key_file[SSL_AIDX_MAX];
X509*public_cert[SSL_AIDX_MAX];
EVP_PKEY*private_key[SSL_AIDX_MAX];
} ssl_server_pkey_info_t;
typedef struct {
/*
* client (e.g. proxy) can have any number of
* cert/key pairs
*/
const char *client_certificate_file;
const char *client_certificate_path;
STACK_OF(X509_INFO) *certs;
} ssl_client_pkey_info_t;
typedef struct {
SSL_CTX *ssl_ctx;
ssl_method_type_e method; /* client or server */
union {
/* we are one or the other */
ssl_server_pkey_info_t server;
ssl_client_pkey_info_t client;
} pkey_info;
/* config for handling encrypted keys */
ssl_pphrase_t pass_phrase_dialog_type;
const char *pass_phrase_dialog_path;
/* known/trusted CAs */
const char *ca_certificate_path;
const char *ca_certificate_file;
const char *certificate_chain;
/* certificate revocation list */
const char *crl_path;
const char *crl_file;
X509_STORE *crl_store;
const char *cipher_suite;
ssl_proto_t protocol;
/* for client or downstream server */
int verify_depth;
ssl_verify_t verify_client;
int session_cache_timeout;
} ssl_srv_ctx_t;
typedef struct {
SSLModConfigRec *mc;
const char*vhost_id;
BOOL enabled;
apr_file_t*log_file;
intlog_level;
ssl_srv_ctx_t *server;
ssl_srv_ctx_t *proxy;
} ssl_srv_config_t; /* was SSLSrvConfigRec */
httpd-test + cvs head
to those working on filters, please make sure httpd-test/perl-framework
tests are passing. i'm seeing a bunch fail at the moment, a couple with
"response had protocol HTTP/0.9 (headers not sent?)" and various
segvs:
filter/case, filter/input_body:
Program received signal SIGSEGV, Segmentation fault.
0x08073f04 in add_any_filter_handle (frec=0x8167130, ctx=0x0, r=0x81f6c90,
c=0x0, r_filters=0x81f6e00, p_filters=0x81f6e08, c_filters=0x40)
at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:345
345 if (*r_filters != *c_filters) {
(gdb) p *r_filters
$1 = (ap_filter_t *) 0x81ae6b8
(gdb) p *c_filters
Cannot access memory at address 0x40
protocol/echo, protocol/nntp-like, any ssl request:
#0 0x08073fde in add_any_filter_handle (frec=0x80a2cf0, ctx=0x81b7370,
r=0x0,
c=0x81ae050, r_filters=0x0, p_filters=0x0, c_filters=0x81ae08c)
at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:368
368 if (fscan->next->prev == fscan) {
(gdb) p fscan
$1 = (ap_filter_t *) 0x81b7328
(gdb) p fscan->next
$2 = (ap_filter_t *) 0x0
Re: cvs commit: httpd-2.0/modules/ssl mod_ssl.h ssl_engine_dh.cssl_engine_init.c ssl_engine_kernel.c ssl_engine_rand.c ssl_scache_dbm.cssl_scache_shmcb.c ssl_scache_shmht.c
On Mon, 25 Feb 2002, Cliff Woolley wrote: > ssl_rand_seed() runs on every request if you configure it that way. this is true, when 'SSLRandomSeed connect builtin' is configured, which is the default. not sure how much the scoreboard image changes between requests. though somewhat related, i still have on my ssl performance todo-list, optimizing 'SSLRandomSeed connect builtin'. first problem is that RAND_seed() mutex locks in a threaded MPM. and there's three calls to it at connect time: 1st - adds pid (already happened at startup) and time() (which RAND_seed already does everytime you call it). i'm no random number expert, but would be surprised if seed with the same values is useful. 2nd - stackdata (from unsigned char stackdata[256]), no idea how random that'll be. 3rd - scoreboard data better sources can be configured, but require reading from a file, running an external program or talking to an EGD. i think builtin could be improved. how about if threads are available, spawn a low priority thread to gather entropy using apr_generate_random_bytes() which mod_ssl can grab as needed without blocking?
[patch] better mod_ssl restart handling
mod_ssl is hardwired only to initialize certain things on the first module
init during startup. the only reason i can see is because the builtin
SSLPassPhraseDialog can only read the passphrase from the tty before
detach. but if SSLPassPhraseDialog is exec: or the server key is not
passphrase encrypted, there is no reason not to do a full startup/teardown
of these things each time on restart.
currently it is not possible to add LoadModule mod_ssl.so to an already
running server (core dumps), nor is it possible to change the server
cert/key on restart (continues to use the cert/key read at initial
startup).
patch below makes both possible by removing the init counter and doing a
full startup/teardown on restarts. adds a special case when
SSLPassPhraseDialog is builtin and server has detached, to reuse the
existing private key for a vhost if the key source file/mtime have not
changed.
Index: modules/ssl/mod_ssl.h
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/mod_ssl.h,v
retrieving revision 1.55
diff -u -r1.55 mod_ssl.h
--- modules/ssl/mod_ssl.h 18 Jan 2002 23:26:46 - 1.55
+++ modules/ssl/mod_ssl.h 22 Feb 2002 03:58:00 -
@@ -462,6 +462,8 @@
typedef struct {
long int nData;
unsigned char *cpData;
+char *source_file;
+apr_time_t source_mtime;
} ssl_asn1_t;
/*
@@ -501,7 +503,6 @@
pid_t pid;
apr_pool_t *pPool;
BOOLbFixed;
-int nInitCount;
int nSessionCacheMode;
char *szSessionCacheDataFile;
int nSessionCacheDataSize;
Index: modules/ssl/ssl_engine_config.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_config.c,v
retrieving revision 1.20
diff -u -r1.20 ssl_engine_config.c
--- modules/ssl/ssl_engine_config.c 29 Nov 2001 06:15:01 - 1.20
+++ modules/ssl/ssl_engine_config.c 22 Feb 2002 03:58:00 -
@@ -90,7 +90,6 @@
/*
* initialize per-module configuration
*/
-mc->nInitCount = 0;
mc->nSessionCacheMode = SSL_SCMODE_UNSET;
mc->szSessionCacheDataFile = NULL;
mc->nSessionCacheDataSize = 0;
Index: modules/ssl/ssl_engine_init.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_init.c,v
retrieving revision 1.25
diff -u -r1.25 ssl_engine_init.c
--- modules/ssl/ssl_engine_init.c 16 Feb 2002 18:35:21 - 1.25
+++ modules/ssl/ssl_engine_init.c 22 Feb 2002 03:58:01 -
@@ -89,8 +89,6 @@
ssl_config_global_create(s); /* just to avoid problems */
ssl_config_global_fix(mc);
-mc->nInitCount++;
-
/*
* try to fix the configuration and open the dedicated SSL
* logfile as early as possible
@@ -121,78 +119,22 @@
/*
* Identification
*/
-if (mc->nInitCount == 1) {
-ssl_log(s, SSL_LOG_INFO, "Server: %s, Interface: %s, Library: %s",
-AP_SERVER_BASEVERSION,
-ssl_var_lookup(p, s, NULL, NULL, "SSL_VERSION_INTERFACE"),
-ssl_var_lookup(p, s, NULL, NULL, "SSL_VERSION_LIBRARY"));
-}
-
-/*
- * Initialization round information
- */
-if (mc->nInitCount == 1)
-ssl_log(s, SSL_LOG_INFO, "Init: 1st startup round (still not detached)");
-else if (mc->nInitCount == 2)
-ssl_log(s, SSL_LOG_INFO, "Init: 2nd startup round (already detached)");
-else
-ssl_log(s, SSL_LOG_INFO, "Init: %d%s restart round (already detached)",
-mc->nInitCount-2, (mc->nInitCount-2) == 1 ? "st" : "nd");
+ssl_log(s, SSL_LOG_INFO, "Server: %s, Interface: %s, Library: %s",
+AP_SERVER_BASEVERSION,
+ssl_var_lookup(p, s, NULL, NULL, "SSL_VERSION_INTERFACE"),
+ssl_var_lookup(p, s, NULL, NULL, "SSL_VERSION_LIBRARY"));
-/*
- * The initialization phase inside the Apache API is totally bogus.
- * We actually have three non-trivial problems:
- *
- * 1. Under Unix the API does a 2-round initialization of modules while
- * under Win32 it doesn't. This means we have to make sure that at
- * least the pass phrase dialog doesn't occur twice. We overcome this
- * problem by using a counter (mc->nInitCount) which has to
- * survive the init rounds.
- *
- * 2. Between the first and the second round Apache detaches from
- * the terminal under Unix. This means that our pass phrase dialog
- * _has_ to be done in the first round and _cannot_ be done in the
- * second round.
- *
- * 3. When Dynamic Shared Object (DSO) mechanism is used under Unix the
- * module segment (code & data) gets unloaded and re-loaded between
- * the first and the second round. This means no glob
Re: APR_BRIGADE_NORMALIZE
i thought it was added as a workaround during one of the mod_ssl filter rewrites. during the last one i tried removing APR_BRIGADE_NORMALIZE from core.c and all tests in httpd-test passed except for protocol/echo and protocol/nntp_like (which are the same code in the place where the problem shows up). so you might want to try debugging with one of those tests to find the culprit.
Re: mod_ssl input filtering WAS Re: [PATCH] Re: PHP Apache2Filter
On Sun, 20 Jan 2002, Justin Erenkrantz wrote: > Oh, also, mod_ssl may want to take advantage of the new > apr_brigade_split_line call (see how core_input_filter calls it). > I'm rewriting ap_rgetline in my tree, so things are sort of a mess > in my tree. But, it should ease the complexity a bit. What do you > think about that? I know that was one of your complaints in the > recent input filtering changes in mod_ssl. -- justin sounds great to me.
Re: [PATCH] Re: PHP Apache2Filter
On Sun, 20 Jan 2002, Justin Erenkrantz wrote: > Also, be aware that the *readbytes may change to readbytes. I > don't know who has commit access to PHP, but it'd be nice if > someone over there applied the following for now. =) -- justin i've adjusted modperl and php (with the same fix as your patch) just a few minutes ago. nice work btw, makes things much cleaner.
Re: [patch] new mod_ssl input filter
On Wed, 16 Jan 2002, Justin Erenkrantz wrote: > Perhaps you *could* read all of the brigade in the getline case in > bio_bucket_io_read, but that's not a sticking point (as I see your > point - ap_getline *should* be able to pick up on an incomplete > line). i was just trying to avoid blocking forever if all available data had already been read. probably could be done a better way. i was sorta hoping core_input_filter could be split to avoid the getline duplication, but that is another topic. > Assuming that you've run this through httpd-test. -- justin yes. apache/limit 9,10 fail with t/TEST -ssl, but that was also the case before the patch. i debugged a bit and might be an issue on the client side. i will look into it later.
detach note?
wondering if we could have a mechanism where MPMs set some sort of note after calling apr_proc_detach()? reason is, mod_ssl is hardwired only to initialize certain things on the first module init during startup. but the only reason i can see is because the builtin SSLPassPhraseDialog can only read the passphrase from the tty before detach. but if SSLPassPhraseDialog is exec: or the server key is not passphrase encrypted, there is no reason not to do a full startup/teardown of these things each time on restart. if mod_ssl could know httpd is already detached, things could be handled properly without the existing hardwired counter. currently it is not possible to add LoadModule mod_ssl.so to an already running server, nor is it possible to change the server key on restart.
Re: [PATCH - 2] cleaning up mod_ssl
On Wed, 9 Jan 2002, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > Hi, > Here comes a more complete patch..Any suggestions, comments are > appreciated. looks great to me, applied to cvs. might be worth submitting those macros back to OpenSSL and put #ifndefs or similar around the current ones.
RE: cvs commit: httpd-2.0/modules/ssl mod_ssl.h ssl_engine_pphrase.c ssl_util.c
On Wed, 9 Jan 2002, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > mod_ssl build is broken because of the new argument introduced in > ssl_util_ppopen().. [build breaks for ssl_engine_rand.c] compiles again and works now too.
Re: trouble with httpd-2.0 HEAD
everything is ok now after blowing away the cvs tree and checking out from scratch. either something stale in the cvs tree, or a bug in my build script. sorry for the hassle.
Re: trouble with httpd-2.0 HEAD
On Sat, 5 Jan 2002, Justin Erenkrantz wrote: > Huh. That's what I have and it works. What does config.status > say for APR_INCLUDES: nada. there's no reference to APR_INCLUDES in there at all. are you using a --srcdir? that's my main suspect, though i haven't tried without it yet. > It looks like it isn't getting substituted for you. It's working > here in VPATH and non-VPATH builds. You could try blowing away > your config.cache. -- justin it was already blown away before buildconf and configure were run.
Re: trouble with httpd-2.0 HEAD
On Sat, 5 Jan 2002, Justin Erenkrantz wrote: > How is APR-util's configure script getting the --with-apr > option (see config.nice)? -- justin % cat srclib/apr-util/config.nice #! /bin/sh # # Created by configure CFLAGS="-Wall -g"; export CFLAGS "/usr/local/apache/src/httpd-2.0-cvs/srclib/apr-util/configure" \ "--prefix=/usr/local/apache/install/prefork-debug-shared-all-exp" \ "--with-mpm=prefork" \ "--srcdir=/usr/local/apache/src/httpd-2.0-cvs" \ "--enable-maintainer-mode" \ "--enable-mods-shared=all" \ "--enable-modules=all" \ "--enable-example" \ "--enable-case_filter" \ "--enable-case_filter_in" \ "--enable-cache" \ "--enable-echo" \ "--enable-deflate" \ "--disable-auth_dbm" \ "--disable-auth_db" \ "--disable-auth_digest" \ "--enable-ssl=static" \ "--with-ssl=/usr/local/ssl" \ "--cache-file=../.././config.cache" \ "--srcdir=/usr/local/apache/src/httpd-2.0-cvs/srclib/apr-util" \ "--with-apr=../apr" \ "--prefix=/usr/local/apache/install/prefork-debug-shared-all-exp" \ "$@" % cat srclib/apr/config.nice #! /bin/sh # # Created by configure CFLAGS="-Wall -g"; export CFLAGS "/usr/local/apache/src/httpd-2.0-cvs/srclib/apr/configure" \ "--prefix=/usr/local/apache/install/prefork-debug-shared-all-exp" \ "--with-mpm=prefork" \ "--srcdir=/usr/local/apache/src/httpd-2.0-cvs" \ "--enable-maintainer-mode" \ "--enable-mods-shared=all" \ "--enable-modules=all" \ "--enable-example" \ "--enable-case_filter" \ "--enable-case_filter_in" \ "--enable-cache" \ "--enable-echo" \ "--enable-deflate" \ "--disable-auth_dbm" \ "--disable-auth_db" \ "--disable-auth_digest" \ "--enable-ssl=static" \ "--with-ssl=/usr/local/ssl" \ "--cache-file=../.././config.cache" \ "--srcdir=/usr/local/apache/src/httpd-2.0-cvs/srclib/apr" \ "--prefix=/usr/local/apache/install/prefork-debug-shared-all-exp" \ "$@"
Re: trouble with httpd-2.0 HEAD
On Sat, 5 Jan 2002, Justin Erenkrantz wrote: > @APR_INCLUDES@ is not being substituted properly. You reran buildconf > and configure? yeah, the script i use always blows away the old build tree and re-runs buildconf and configure.
trouble with httpd-2.0 HEAD
updating for the first time in 2 weeks, blowing up here: /bin/sh /usr/local/apache/build/prefork-debug-shared-all-exp/srclib/apr/libtool --silent --mode=compile gcc -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread -Wall -g -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -I/usr/local/apache/build/prefork-debug-shared-all-exp/srclib/apr-util/include -I/usr/local/apache/src/httpd-2.0-cvs/srclib/apr-util/include @APR_INCLUDES@ -c /usr/local/apache/src/httpd-2.0-cvs/srclib/apr-util/buckets/apr_buckets_file.c && touch apr_buckets_file.lo gcc: cannot specify -o with -c or -S and multiple compilations make[4]: *** [apr_buckets_file.lo] Error 1 same configure args were working fine back then, other than mod_auth_digest not building. i think that was related to using --srcdir, maybe this problem is too? % cat config.nice #! /bin/sh # # Created by configure CFLAGS="-Wall -g"; export CFLAGS "/usr/local/apache/src/httpd-2.0-cvs/configure" \ "--prefix=/usr/local/apache/install/prefork-debug-shared-all-exp" \ "--with-mpm=prefork" \ "--srcdir=/usr/local/apache/src/httpd-2.0-cvs" \ "--enable-maintainer-mode" \ "--enable-mods-shared=all" \ "--enable-modules=all" \ "--enable-example" \ "--enable-case_filter" \ "--enable-case_filter_in" \ "--enable-cache" \ "--enable-echo" \ "--enable-deflate" \ "--disable-auth_dbm" \ "--disable-auth_db" \ "--disable-auth_digest" \ "--enable-ssl=static" \ "--with-ssl=/usr/local/ssl" \ "$@"
Re: [PATCH] get mod_ssl to work again
On Thu, 20 Dec 2001, Justin Erenkrantz wrote: > so that we can always call apr_generate_random_bytes()? oh, i assumed we already could. +1 on whatever it takes to make that function usable on all platforms.
Re: [PATCH] get mod_ssl to work again
On Thu, 20 Dec 2001, Daniel Lopez wrote: > > /dev/urandom is not available in all platforms right, which is why it is not portable to use directly. /dev/random is also not available on all platforms, so apr uses whats available to provide the same functionality for the given platform in apr_generate_random_bytes().
Re: [PATCH] get mod_ssl to work again
On Thu, 20 Dec 2001, Aaron Bannert wrote: > /dev/urandom won't block, so maybe we could live with that once per > request and use the /dev/random for startup. right, only problem is apr doesn't support /dev/urandom. maybe we need an apr_generate_urandom_bytes() function or a non-blocking flag to apr_generate_random_bytes()? modssl already has: SSLRandomSeed connect file:/dev/urandom 512 but something more portable would be nice.
Re: [PATCH] get mod_ssl to work again
On Thu, 20 Dec 2001, Justin Erenkrantz wrote: > FWIW, DougM submitted this function to flood to generate OpenSSL > entropy. I'd almost suggest somehow factoring this into apr-util > since flood needs this too (and doesn't have a scoreboard). that function was derived from mod_ssl-1.xx and have learned some things since. i recently noticed OpenSSL internally calls RAND_seed(time()) during negotiation. so i was planning to remove that same call from modssl or at least change it to use r->request_time. (main goal: getting rid of time() and getpid() syscalls on every connect) since flood only seeds at startup time, might be better for you just to use apr_generate_random_bytes(). don't want to use that in modssl for 'SSLRandomSeed builtin connect', since /dev/random blocking will be too slow for every connect. but will probably change it to use that for 'SSLRandomSeed builtin startup'.
Re: [PATCH] get mod_ssl to work again
On 18 Dec 2001, Jeff Trawick wrote: > or just an entropy function? why should any module care that it is > from the scoreboard? +1 on that or anything to get mod_ssl working again.
Re: server->port busted
On Wed, 5 Dec 2001, Greg Stein wrote:
> The Port directive used to set the server->port variable. When Port was
> tossed, we also lost the use of server->port. That affects the response of
> ap_get_server_port() and ap_matches_request_vhost().
same problem when there was a Port directive and no Port directive was
configured. configuring ServerName foo:port will fix that.
i was told that was "the expected behavior" back when i posted this patch,
but it still applies..
Date: Thu, 9 Aug 2001 18:59:08 -0700 (PDT)
From: Doug MacEachern <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Listen vs. Port
Message-ID: <[EMAIL PROTECTED]>
if Listen is used to set the server port, and Port is not configured,
ap_get_server_port returns the default port (80). this breaks mod_dir
redirects if Listen is something other than 80. should Listen also set
the server->port (as in the patch below) or is it required that Port must
also be configured?
Index: server/listen.c
===
RCS file: /home/cvs/httpd-2.0/server/listen.c,v
retrieving revision 1.59
diff -u -r1.59 listen.c
--- server/listen.c 2001/07/26 16:36:40 1.59
+++ server/listen.c 2001/08/10 01:51:35
@@ -353,6 +353,10 @@
return "Port must be specified";
}
+if (!cmd->server->port) {
+cmd->server->port = port;
+}
+
alloc_listener(cmd->server->process, host, port);
return NULL;
srand() usage
mod_rewrite has a race condition with threaded mpms:
static int rewrite_rand_init_done = 0;
static void rewrite_rand_init(void)
{
if (!rewrite_rand_init_done) {
srand((unsigned)(getpid()));
rewrite_rand_init_done = 1;
}
return;
}
and mod_ssl calls srand(time(NULL)) on *every* request if
'SSLRandomSeed connect builtin' is configured.
i was thinking there should be an ap_srand() that can be called by modules
in the child_init hook. something like:
static int ap_srand_init = 0;
AP_DECLARE(void) ap_srand(void)
{
if (!ap_srand_init) {
srand(...);
ap_srand_init = 1;
}
}
this will help ensure srand() is only called once per-process and avoid
the race condition. thoughts?
only snag is it looks like all MPMs except for beos call
ap_run_child_init(), any reason the beos mpm shouldn't be calling it?
Re: [patch] major ssl problem
On Mon, 26 Nov 2001, Ryan Bloom wrote: > But, that will only happen if we are modifying the contents. I think the best we > could probably do is get rid of the seek call, and if we change the read API, > the malloc. ok. would be nice if there were an api where caller could provide the buffer and number of bytes to read.
Re: [patch] major ssl problem
On Sat, 24 Nov 2001, Cliff Woolley wrote: > Actually, that's not exactly true. If APR_HAS_MMAP, and the file bucket > is between MMAP_THRESHOLD and MMAP_LIMIT (MMAP_LIMIT is 4MB by default), > then yes, len will be up to 4MB. But if the file bucket is bigger than > 4MB or the system doesn't have MMAP, then len will *never* be bigger than > APR_BUCKET_BUFF_SIZE (8KB). hmm..putting ssl aside, lets say we have a 10Mb file, looking at apr_buckets_file.c:file_read() that's ~1200 calls each to: - malloc for the 8k buffer - seek() for the current offset - read() of 8k for the actual buffer not to mention the APR_BRIGADE_FOREACH loop and whatever else is in between. seems that could use some performance tuning of its own? > I don't know if that affects any of the decisions in the patch (which I > haven't finished looking at), but it was worth mentioning. i still suggest the current patch. even though apr_bucket_read() will break up a file > 4Mb, the pbioWrite buffer will still be filled to the length of the file.
Re: [patch] major ssl problem
actually, i take some of that back, didn't do enough homework. SSL_write
will break the calls to mem_write() into reasonable chunks (~16k).
so we don't need this part of the patch:
+while (len > 0) {
+int wlen = len > AP_IOBUFSIZE ? AP_IOBUFSIZE : len;
+if ((nrd = SSL_write(ssl, buf, wlen)) < 0) {
...
i'll keep digging in and post another patch, but the BIO_bucket concept
still applies.
Re: [patch] major ssl problem
On Fri, 23 Nov 2001, Justin Erenkrantz wrote: > My only question is whether we could end up reading from the bucket > (i.e. calling bucket_read) if we decide to "setaside" the bucket - this > should be possible now with Ryan's latest patches to core_output_filter. > So, might we have to implement bucket_read? -- justin the buckets created by bucket_write() are all standard apr buckets, so that's no problem. bucket_read() would only be called if somebody called BIO_read() on SSLFilterRec->pbioWrite, which never happens.
[patch] disable parent profiling
this is a carry over from 1.3, other mpms would need to
AP_MONCONTROL(1) in the appropriates places..
Index: include/ap_mpm.h
===
RCS file: /home/cvs/httpd-2.0/include/ap_mpm.h,v
retrieving revision 1.31
diff -u -r1.31 ap_mpm.h
--- include/ap_mpm.h2001/11/13 22:42:38 1.31
+++ include/ap_mpm.h2001/11/24 00:22:33
@@ -183,4 +183,18 @@
*/
AP_DECLARE(apr_status_t) ap_mpm_query(int query_code, int *result);
+/* Defining GPROF when compiling uses the moncontrol() function to
+ * disable gprof profiling in the parent, and enable it only for
+ * request processing in children (or in one_process mode). It's
+ * absolutely required to get useful gprof results under linux
+ * because the profile itimers and such are disabled across a
+ * fork(). It's probably useful elsewhere as well.
+ */
+#ifdef GPROF
+extern void moncontrol(int);
+#define AP_MONCONTROL(x) moncontrol(x)
+#else
+#define AP_MONCONTROL(x)
+#endif
+
#endif
Index: server/main.c
===
RCS file: /home/cvs/httpd-2.0/server/main.c,v
retrieving revision 1.102
diff -u -r1.102 main.c
--- server/main.c 2001/11/23 16:35:22 1.102
+++ server/main.c 2001/11/24 00:22:34
@@ -298,6 +298,8 @@
module **mod;
const char *optarg;
+AP_MONCONTROL(0); /* turn of profiling of startup */
+
apr_initialize();
process = create_process(argc, argv);
Index: server/mpm/prefork/prefork.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/prefork/prefork.c,v
retrieving revision 1.222
diff -u -r1.222 prefork.c
--- server/mpm/prefork/prefork.c2001/11/20 18:18:45 1.222
+++ server/mpm/prefork/prefork.c2001/11/24 00:22:35
@@ -759,6 +759,7 @@
}
#endif
RAISE_SIGSTOP(MAKE_CHILD);
+AP_MONCONTROL(1);
/* Disable the parent's signal handlers and set up proper handling in
* the child.
*/
@@ -969,6 +970,10 @@
#endif
set_signals();
+
+if (one_process) {
+AP_MONCONTROL(1);
+}
if (ap_daemons_max_free < ap_daemons_min_free + 1) /* Don't thrash... */
ap_daemons_max_free = ap_daemons_min_free + 1;
[patch] major ssl problem
ssl_io_filter_Output currently does this:
/* read filter */
apr_bucket_read(bucket, &data, &len, APR_BLOCK_READ);
/* write SSL */
n = ssl_io_hook_write(ctx->pssl, (unsigned char *)data, len);
=> above writes into a single memory buffer of at least size len
if ((ret = churn_output(ctx)) != APR_SUCCESS) {
=> above creates a single transient bucket with memory buffer
created above
the problem is that when 'bucket' is a file bucket, len will be the size
of the entire file. so if the file is 200k, 500k, 10Mb, 1Gb, etc., there
is a malloc() for that size plus the additional bytes need for encryption.
and that is just for our copy, the ssl encryption layer mallocs for its
buffer before it is passed to mem_write() (the pbioWrite BIO callback).
patch below works towards solving this problem:
- first by breaking the buffer size fed to SSL_write into AP_IOBUFSIZE or
less size chunks
- change pbioWrite from a memory buffer to a custom BIO BIO_s_bucket.
this allows us to feed buckets down to the core as data is being
written instead of filling the memory buffer first. and making it
possible to avoid an extra copy of the encrypted data.
it still needs to be optimized, see this comment for starters:
* if we use heap buckets we can buffer before flushing to the core
* but this means we have to malloc/free data in each bucket.
* if we use transient buckets, no malloc/free for the data
* but we have to flush right away.
in a nutshell: mallocs / less writev()s vs no mallocs / more writevs()
which is best can be debated. but at the very least, we need to cut down
the size of buffers fed to SSL_write. and a custom BIO will provide us
with the most optimizations options.
Index: modules/ssl/ssl_engine_io.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_io.c,v
retrieving revision 1.44
diff -u -r1.44 ssl_engine_io.c
--- modules/ssl/ssl_engine_io.c 2001/11/19 22:37:57 1.44
+++ modules/ssl/ssl_engine_io.c 2001/11/23 21:46:51
@@ -70,6 +70,230 @@
/* XXX THIS STUFF NEEDS A MAJOR CLEANUP -RSE XXX */
+typedef struct {
+SSLFilterRec *frec;
+conn_rec *c;
+apr_bucket_brigade *bb;
+apr_size_t length;
+char buffer[AP_IOBUFSIZE];
+apr_size_t blen;
+int num_buckets;
+} BIO_bucket_t;
+
+#define BIO_bucket_ptr(bio) (BIO_bucket_t *)bio->ptr
+
+static int bucket_write(BIO *bio, const char *buf, int num);
+static int bucket_read(BIO *bio, char *buf, int size);
+static int bucket_puts(BIO *bio, const char *str);
+static int bucket_gets(BIO *bio, char *str, int size);
+static long bucket_ctrl(BIO *bio, int cmd, long arg1, void *arg2);
+static int bucket_new(BIO *bio);
+static int bucket_free(BIO *bio);
+
+static BIO_METHOD bucket_method = {
+BIO_TYPE_MEM,
+"APR bucket buffer",
+bucket_write,
+bucket_read,
+bucket_puts,
+bucket_gets,
+bucket_ctrl,
+bucket_new,
+bucket_free,
+NULL,
+};
+
+static BIO_METHOD *BIO_s_bucket(void)
+{
+return &bucket_method;
+}
+
+static BIO_bucket_t *BIO_bucket_new(SSLFilterRec *frec, conn_rec *c)
+{
+BIO_bucket_t *b = apr_palloc(c->pool, sizeof(*b));
+
+b->frec = frec;
+b->c = c;
+b->bb = apr_brigade_create(c->pool);
+b->blen = 0;
+b->num_buckets = 0;
+
+return b;
+}
+
+static int BIO_bucket_flush(BIO *bio)
+{
+BIO_bucket_t *b = BIO_bucket_ptr(bio);
+
+if (!(b->blen || b->length)) {
+return APR_SUCCESS;
+}
+
+if (b->blen) {
+apr_bucket *bucket =
+apr_bucket_transient_create(b->buffer,
+b->blen);
+/* we filled this buffer first so add it to the
+ * head of the brigade
+ */
+APR_BRIGADE_INSERT_HEAD(b->bb, bucket);
+b->blen = 0;
+}
+
+b->num_buckets = 0;
+b->length = 0;
+APR_BRIGADE_INSERT_TAIL(b->bb, apr_bucket_flush_create());
+
+return ap_pass_brigade(b->frec->pOutputFilter->next, b->bb);
+}
+
+static int bucket_new(BIO *bio)
+{
+bio->shutdown = 1;
+bio->init = 1;
+bio->num = -1;
+bio->ptr = NULL;
+
+return 1;
+}
+
+static int bucket_free(BIO *bio)
+{
+if (bio == NULL) {
+return 0;
+}
+
+if (bio->shutdown) {
+if ((bio->init) && (bio->ptr != NULL)) {
+BIO_bucket_t *b = BIO_bucket_ptr(bio);
+b->bb = NULL;
+bio->ptr = NULL;
+}
+}
+
+return 1;
+}
+
+static int bucket_read(BIO *bio, char *out, int outl)
+{
+return -1;
+}
+
+#define SSL_MAX_BUCKETS 16 /* MAX_IOVEC_TO_WRITE */
+#define SSL_USE_HEAP_BUCKETS
+
+/*
+ * if we use heap buckets we can buffer before flushing to the core
+ * but this means we have to malloc/free data in each bucket.
+ * if we use transient buckets, no malloc/free for the data
+ * but we have to flush right away.
+ */
+static int bucket_write(BIO *bio
RE: mod_ssl ssl::verify::depth ?
On Wed, 21 Nov 2001, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> If I'm not wrong, what we're trying to do here is to enforce the strongest
> SSLVerifyDepth b/w the directory config and the server-config -
right, but i don't see why ssl::verify::depth was ever needed for that.
i mean, the patch below should continue to do that without this (as far as
i can see) unneeded sslconn->verify_depth.
so we end up with simply:
if (per-dir-verify != unset) {
if (per-dir-verify < per-server-verify) {
rengotiate = TRUE;
}
}
ssl_hook_Access is only going to be called once, the value of
sc->nVerifyDepth isn't going to change even it were called more than once.
Index: modules/ssl/ssl_engine_kernel.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_kernel.c,v
retrieving revision 1.26
diff -u -r1.26 ssl_engine_kernel.c
--- modules/ssl/ssl_engine_kernel.c 2001/11/22 00:42:35 1.26
+++ modules/ssl/ssl_engine_kernel.c 2001/11/22 01:15:37
@@ -518,13 +518,8 @@
* restriction on the certificate chain).
*/
if (dc->nVerifyDepth != UNSET) {
-/* XXX: doesnt look like sslconn->verify_depth is actually used */
-if (!(n = sslconn->verify_depth)) {
-sslconn->verify_depth = n = sc->nVerifyDepth;
-}
-
/* determine whether a renegotiation has to be forced */
-if (dc->nVerifyDepth < n) {
+if (dc->nVerifyDepth < sc->nVerifyDepth) {
renegotiate = TRUE;
ssl_log(r->server, SSL_LOG_TRACE,
"Reduced client verification depth will force renegotiation");
mod_ssl ssl::verify::depth ?
i was about to move the usage of c->notes.ssl::verify::depth to
SSLConnRec.verify_depth and in the process noticed the bloody thing is
never used. the comment says:
/*
* override of SSLVerifyDepth
*
* The depth checks are handled by us manually inside the verify callback
* function and not by OpenSSL internally (and our function is aware of
* both the per-server and per-directory contexts). So we cannot ask
* OpenSSL about the currently verify depth. Instead we remember it in our
* ap_ctx attached to the SSL* of OpenSSL. We've to force the
* renegotiation if the reconfigured/new verify depth is less than the
* currently active/remembered verify depth (because this means more
* restriction on the certificate chain).
*/
but if you look at the patch below, after ssl::verify::depth usage is
replaced, this is only place it is referenced, in ssl_hook_Access:
if (!(n = sslconn->verify_depth)) {
sslconn->verify_depth = n = sc->nVerifyDepth;
}
i see no reason why that couldn't just be:
n = sc->nVerifyDepth;
can anybody see something i'm missing? mod_ssl 1.x is no different.
Index: mod_ssl.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/mod_ssl.c,v
retrieving revision 1.34
diff -u -r1.34 mod_ssl.c
--- mod_ssl.c 2001/11/21 22:29:14 1.34
+++ mod_ssl.c 2001/11/21 23:17:16
@@ -274,7 +274,6 @@
SSL_set_app_data(ssl, c);
apctx = apr_table_make(c->pool, AP_CTX_MAX_ENTRIES);
apr_table_setn(apctx, "ssl::request_rec", NULL);
-apr_table_setn(apctx, "ssl::verify::depth", AP_CTX_NUM2PTR(0));
SSL_set_app_data2(ssl, apctx);
sslconn->ssl = ssl;
Index: mod_ssl.h
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/mod_ssl.h,v
retrieving revision 1.38
diff -u -r1.38 mod_ssl.h
--- mod_ssl.h 2001/11/21 22:29:14 1.38
+++ mod_ssl.h 2001/11/21 23:17:16
@@ -462,6 +462,7 @@
ssl_shutdown_type_e shutdown_type;
const char *verify_info;
const char *verify_error;
+int verify_depth;
} SSLConnRec;
typedef struct {
Index: ssl_engine_kernel.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_kernel.c,v
retrieving revision 1.24
diff -u -r1.24 ssl_engine_kernel.c
--- ssl_engine_kernel.c 2001/11/21 22:29:14 1.24
+++ ssl_engine_kernel.c 2001/11/21 23:17:18
@@ -371,11 +371,9 @@
STACK_OF(SSL_CIPHER) *skCipherOld;
STACK_OF(SSL_CIPHER) *skCipher;
SSL_CIPHER *pCipher;
-apr_table_t *apctx;
int nVerifyOld;
int nVerify;
int n;
-void *vp;
int rc;
dc = myDirConfig(r);
@@ -522,13 +520,10 @@
* restriction on the certificate chain).
*/
if (dc->nVerifyDepth != UNSET) {
-apctx = (apr_table_t *)SSL_get_app_data2(ssl);
-if ((vp = (void *)apr_table_get(apctx, "ssl::verify::depth")) != NULL)
-n = (int)AP_CTX_PTR2NUM(vp);
-else
-n = sc->nVerifyDepth;
-apr_table_setn(apctx, "ssl::verify::depth",
- (const char *)AP_CTX_NUM2PTR(dc->nVerifyDepth));
+if (!(n = sslconn->verify_depth)) {
+sslconn->verify_depth = n = sc->nVerifyDepth;
+}
+
/* determine whether a renegotiation has to be forced */
if (dc->nVerifyDepth < n) {
renegotiate = TRUE;
[patch] mod_setenvif r->notes--
first hunk switches from using r->notes to r->request_config, which is
much faster. and important considering that code runs at least twice for
every request if mod_setenvif is loaded.
second gets rids of a strcmp. if there is a '!' in val, it will never be
more than that.
Index: modules/metadata/mod_setenvif.c
===
RCS file: /home/cvs/httpd-2.0/modules/metadata/mod_setenvif.c,v
retrieving revision 1.31
diff -u -r1.31 mod_setenvif.c
--- modules/metadata/mod_setenvif.c 2001/11/11 22:31:04 1.31
+++ modules/metadata/mod_setenvif.c 2001/11/21 19:40:45
@@ -411,8 +411,9 @@
int i, j;
char *last_name;
-if (apr_table_get(r->notes, SEI_MAGIC_HEIRLOOM) == NULL) {
- apr_table_set(r->notes, SEI_MAGIC_HEIRLOOM, "post-read done");
+if (!ap_get_module_config(r->request_config, &setenvif_module)) {
+ap_set_module_config(r->request_config, &setenvif_module,
+ SEI_MAGIC_HEIRLOOM);
sconf = (sei_cfg_rec *) ap_get_module_config(r->server->module_config,
&setenvif_module);
}
@@ -493,7 +494,7 @@
elts = (const apr_table_entry_t *) arr->elts;
for (j = 0; j < arr->nelts; ++j) {
-if (!strcmp(elts[j].val, "!")) {
+if (*(elts[j].val) == '!') {
apr_table_unset(r->subprocess_env, elts[j].key);
}
else {
[patch] mod_ssl + c->notes--
mod_ssl currently does quite a bit of apr_table_{get,set}s. it would be
much faster to use c->conn_config instead. the patch below attaches a new
SSLConnRec structure to the c->conn_config and replaces all usage of
apr_table_{get,set}(c->notes, "ssl") with conn_config. if this approach
is ok, there are a few more c->notes table entries that could be moved to
the conn_config.
Index: modules/ssl/mod_ssl.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/mod_ssl.c,v
retrieving revision 1.31
diff -u -r1.31 mod_ssl.c
--- modules/ssl/mod_ssl.c 2001/10/11 01:49:21 1.31
+++ modules/ssl/mod_ssl.c 2001/11/21 04:02:00
@@ -224,11 +224,12 @@
SSL *ssl;
unsigned char *cpVHostID;
char *cpVHostMD5;
+SSLConnRec *sslconn = apr_pcalloc(c->pool, sizeof(*sslconn));
/*
* Create SSL context
*/
-apr_table_setn(c->notes, "ssl", NULL);
+myConnConfigSet(c, sslconn);
/*
* Immediately stop processing if SSL is disabled for this connection
@@ -258,7 +259,6 @@
if ((ssl = SSL_new(sc->pSSLCtx)) == NULL) {
ssl_log(c->base_server, SSL_LOG_ERROR|SSL_ADD_SSLERR,
"Unable to create a new SSL connection from the SSL context");
-apr_table_setn(c->notes, "ssl", NULL);
c->aborted = 1;
return DECLINED; /* XXX */
}
@@ -268,7 +268,6 @@
strlen(cpVHostMD5))) {
ssl_log(c->base_server, SSL_LOG_ERROR|SSL_ADD_SSLERR,
"Unable to set session id context to `%s'", cpVHostMD5);
-apr_table_setn(c->notes, "ssl", NULL);
c->aborted = 1;
return DECLINED; /* XXX */
}
@@ -278,7 +277,7 @@
apr_table_setn(apctx, "ssl::verify::depth", AP_CTX_NUM2PTR(0));
SSL_set_app_data2(ssl, apctx);
-apr_table_setn(c->notes, "ssl", (const char *)ssl);
+sslconn->ssl = ssl;
/*
* Configure callbacks for SSL connection
@@ -308,6 +307,7 @@
static apr_status_t ssl_abort(SSLFilterRec *pRec, conn_rec *c)
{
+SSLConnRec *sslconn = myConnConfig(c);
/*
* try to gracefully shutdown the connection:
* - send an own shutdown message (be gracefully)
@@ -320,7 +320,7 @@
SSL_smart_shutdown(pRec->pssl);
SSL_free(pRec->pssl);
pRec->pssl = NULL; /* so filters know we've been shutdown */
-apr_table_setn(c->notes, "ssl", NULL);
+sslconn->ssl = NULL;
c->aborted = 1;
return APR_EGENERAL;
Index: modules/ssl/mod_ssl.h
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/mod_ssl.h,v
retrieving revision 1.34
diff -u -r1.34 mod_ssl.h
--- modules/ssl/mod_ssl.h 2001/10/11 01:49:21 1.34
+++ modules/ssl/mod_ssl.h 2001/11/21 04:02:00
@@ -196,6 +196,10 @@
#define cfgMergeBool(el)cfgMerge(el, UNSET)
#define cfgMergeInt(el) cfgMerge(el, UNSET)
+#define myConnConfig(c) \
+(SSLConnRec *)ap_get_module_config(c->conn_config, &ssl_module)
+#define myConnConfigSet(c, val) \
+ap_set_module_config(c->conn_config, &ssl_module, val)
#define myModConfig(srv) (SSLModConfigRec *)ssl_util_getmodconfig(srv, "ssl_module")
#define mySrvConfig(srv) (SSLSrvConfigRec *)ap_get_module_config(srv->module_config,
&ssl_module)
#define myDirConfig(req) (SSLDirConfigRec *)ap_get_module_config(req->per_dir_config,
&ssl_module)
@@ -445,6 +449,10 @@
apr_bucket_brigade *rawb; /* encrypted input */
apr_bucket_brigade *b; /* decrypted input */
} SSLFilterRec;
+
+typedef struct {
+SSL *ssl;
+} SSLConnRec;
typedef struct {
apr_pool_t *pPool;
Index: modules/ssl/ssl_engine_kernel.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_kernel.c,v
retrieving revision 1.20
diff -u -r1.20 ssl_engine_kernel.c
--- modules/ssl/ssl_engine_kernel.c 2001/11/12 22:01:14 1.20
+++ modules/ssl/ssl_engine_kernel.c 2001/11/21 04:02:02
@@ -146,7 +146,7 @@
/* deallocate the SSL connection */
SSL_free(ssl);
-apr_table_setn(conn->notes, "ssl", NULL);
+sslconn->ssl = NULL;
filter->pssl = NULL; /* so filters know we've been shutdown */
return APR_SUCCESS;
@@ -157,6 +157,7 @@
*/
int ssl_hook_ReadReq(request_rec *r)
{
+SSLConnRec *sslconn = myConnConfig(r->connection);
SSL *ssl;
apr_table_t *apctx;
@@ -164,7 +165,7 @@
* Get the SSL connection structure and perform the
* delayed interlinking from SSL back to request_rec
*/
-ssl = (SSL *)apr_table_get(r->connection->notes, "ssl");
+ssl = sslconn->ssl;
if (ssl != NULL) {
apctx = (apr_table_t *)SSL_get_app_data2(ssl);
apr_table_setn(apctx, "ssl::request_rec", (const char *)r);
@@ -191,7 +192,9 @@
*/
int ssl_hook_Translate(request_rec *r)
{
-if (apr_table_get(r->connection->notes, "ssl") == NULL)
+SSLConnRec *sslconn = myConnConfig(r->connection)
Re: core output filter buffering
On Tue, 20 Nov 2001, Bill Stoddard wrote: > What is the source of the bytes being written? Is it a pipe? Or a file? a heap bucket. i guess my question should be: when using memory (heap,transient,pool,etc) buckets, what is the optimal apr_brigade_length() to build up before passing to core_output_filter?
Re: [PATCH] apache core dumps if you call ap_note_basic_auth_failurewhen auth type is null
On Tue, 20 Nov 2001, sterling wrote:
> Hi -
>
> Set up an auth directory without AuthType but with require valid-user and
> AuthName and load an auth module that uses ap_note_basic_auth_failure...
> el kabong!! this patch stops the coro dumpo.
this has bitten others in 1.x too. ended up adding protection in the
modperl wrapper functions. i applied a slightly different version to
prevent the same problem in ap_note_auth_failure(). and also changed
if (type && strcasecmp(ap_auth_type(r), "Basic"))
to
if (!type || ...)
cause i don't think it should set the *-Authenticate header if there is no
AuthType configured, right? or maybe ap_auth_type() should default to
Basic?
Index: server/protocol.c
===
RCS file: /home/cvs/httpd-2.0/server/protocol.c,v
retrieving revision 1.52
diff -u -r1.52 protocol.c
--- server/protocol.c 2001/11/12 23:49:06 1.52
+++ server/protocol.c 2001/11/21 03:10:39
@@ -756,15 +756,25 @@
AP_DECLARE(void) ap_note_auth_failure(request_rec *r)
{
-if (!strcasecmp(ap_auth_type(r), "Basic"))
-ap_note_basic_auth_failure(r);
-else if (!strcasecmp(ap_auth_type(r), "Digest"))
-ap_note_digest_auth_failure(r);
+const char *type = ap_auth_type(r);
+if (type) {
+if (!strcasecmp(type, "Basic"))
+ap_note_basic_auth_failure(r);
+else if (!strcasecmp(type, "Digest"))
+ap_note_digest_auth_failure(r);
+}
+/* XXX: else there is no AuthType configured
+ * should we log an error or something ?
+ */
}
AP_DECLARE(void) ap_note_basic_auth_failure(request_rec *r)
{
-if (strcasecmp(ap_auth_type(r), "Basic"))
+const char *type = ap_auth_type(r);
+/* if there is no AuthType configure or it is something other than
+ * Basic, let ap_note_auth_failure() deal with it
+ */
+if (!type || strcasecmp(type, "Basic"))
ap_note_auth_failure(r);
else
apr_table_setn(r->err_headers_out,
core output filter buffering
can someone explain how the core output buffering is supposed to work?
if you look at
httpd-test/perl-framework/c-modules/test_pass_brigade/mod_test_pass_brigade.c
this intentionally creates a brigade with just one bucket and calls
ap_pass_brigade with that bucket. you can make a request like so:
http://localhost:8529/test_pass_brigade?1024,50
which means use a buffer size of 1024 bytes and send 500k total.
with the patch below for tracing i see this in the error_log:
writev 15543 bytes
writev 16384 bytes
writev 10240 bytes
writev 8192 bytes
... a bunch of 8192's ...
writev 7456 bytes
writev 0 bytes
then with 8192,50:
writev 41143 bytes
writev 8192 bytes
... a bunch of 8192's ...
writev 288 bytes
writev 0 bytes
is this the expected behavior? reason i am asking is that mod_ssl pretty
much does what mod_test_pass_brigade.c does with 8192 size buffers. i
have a patch in the works to optimize that, but want to make sure core
output filter is behaving as expected first. i thought it would buffer
until it could fill AP_MIN_BYTES_TO_WRITE * MAX_IOVEC_TO_WRITE. but then
again, i guess there is a reason it doesn't, since the OLD_WRITE filter
does its own buffering. insight greatly appreciated, thanks.
p.s.
i realize the answer is probably buried in the archives, maybe somebody
wants to write a documented summary?
--- server/core.c 2001/11/19 22:36:20 1.100
+++ server/core.c 2001/11/20 22:52:56
@@ -3201,7 +3201,7 @@
}
else {
apr_size_t unused_bytes_sent;
-
+fprintf(stderr, "writev %d bytes\n", nbytes);
rv = writev_it_all(net->client_socket,
vec, nvec,
nbytes, &unused_bytes_sent);
[patch] AP_MODE_INIT
i mentioned a while back that i had hacked jim winstead's "colobus" NNTP
server (designed to run under tcpserver or inetd) into a protocol handler
using modperl-2.0. and that i had it working with mod_ssl. however, to
get it working with ssl required a special case hack that didn't always
work. nntp needs to respond to the client before the client sends any
request data. ftp has a similar requirement, i imagine other protocols
may as well. the ssl filter currently assumes we will be reading request
data from the client first and does the handshake at that time. if we try
to write the nntp welcome message before reading any client data, the
handshake hasn't happened and things break. the patch below allows such a
protocol module to trigger the handshake, which is a noop without ssl in
the filter chain.
for a simple example of what needs to happen, see:
httpd-test/perl-framework/c-modules/nntp_like/mod_nntp_like.c
with this patch applied the test works both with and without ssl.
if somebody sees a better way todo this, you can use that test to develop
it. or i can take a shot if there are other suggestions.
Index: include/util_filter.h
===
RCS file: /home/cvs/httpd-2.0/include/util_filter.h,v
retrieving revision 1.60
diff -u -r1.60 util_filter.h
--- include/util_filter.h 2001/10/08 16:44:04 1.60
+++ include/util_filter.h 2001/11/16 02:08:11
@@ -97,7 +97,12 @@
* ::APR_EOF otherwise. The filter must not return any buckets of
* data. Data returned on a subsequent call, when mode is
* ::AP_MODE_BLOCKING or ::AP_MODE_NONBLOCKING. */
-AP_MODE_PEEK
+AP_MODE_PEEK,
+/*
+ * the filter should initialize the connection if needed,
+ * NNTP or FTP over SSL for example.
+ */
+AP_MODE_INIT
} ap_input_mode_t;
/**
Index: modules/ssl/ssl_engine_io.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_io.c,v
retrieving revision 1.43
diff -u -r1.43 ssl_engine_io.c
--- modules/ssl/ssl_engine_io.c 2001/11/15 20:55:13 1.43
+++ modules/ssl/ssl_engine_io.c 2001/11/16 02:08:12
@@ -202,6 +202,15 @@
int found_eos = 0, n;
char buf[1024];
apr_status_t rv;
+int do_handshake = (eMode == AP_MODE_INIT);
+
+if (do_handshake) {
+/* protocol module needs to handshake before sending
+ * data to client (e.g. NNTP or FTP)
+ */
+*readbytes = AP_IOBUFSIZE;
+eMode = AP_MODE_NONBLOCKING;
+}
/* Flush the output buffers. */
churn_output(pRec);
@@ -213,6 +222,13 @@
/* If we have nothing in the raw brigade, get some more. */
if (APR_BRIGADE_EMPTY(ctx->rawb)) {
+if (do_handshake) {
+/*
+ * ap_get_brigade with AP_MODE_INIT should always be called
+ * in non-blocking mode, but we need to block here
+ */
+eMode = AP_MODE_BLOCKING;
+}
rv = ap_get_brigade(f->next, ctx->rawb, eMode, readbytes);
if (rv != APR_SUCCESS)
@@ -289,6 +305,11 @@
*/
rv = ssl_hook_process_connection(pRec);
+if (do_handshake && (rv == APR_SUCCESS)) {
+/* don't block after the handshake */
+eMode = AP_MODE_NONBLOCKING;
+}
+
/* Flush again. */
churn_output(pRec);
@@ -322,8 +343,12 @@
return APR_SUCCESS;
}
if (rv == SSL_ERROR_WANT_READ) {
+/* if eMode was originally AP_MODE_INIT,
+ * need to reset before we recurse
+ */
+ap_input_mode_t mode = do_handshake ? AP_MODE_INIT : eMode;
apr_off_t tempread = AP_IOBUFSIZE;
-return churn_input(pRec, eMode, &tempread);
+return churn_input(pRec, mode, &tempread);
}
return rv;
}
Index: server/core.c
===
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.98
diff -u -r1.98 core.c
--- server/core.c 2001/11/15 20:49:53 1.98
+++ server/core.c 2001/11/16 02:08:14
@@ -2790,6 +2790,20 @@
apr_size_t len;
int keptalive = f->c->keepalive == 1;
+if (mode == AP_MODE_INIT) {
+/*
+ * this mode is for filters that might need to 'initialize'
+ * a connection before reading request data from a client.
+ * NNTP over SSL for example needs to handshake before the
+ * server sends the welcome message.
+ * such filters would have changed the mode before this point
+ * is reached. however, protocol modules such as NNTP should
+ * not need to know anything about SSL. given the example, if
+ * SSL is not in the filter chain, AP_MODE_INIT is a noop.
+ */
+return APR_SUCCESS;
+}
+
if (!ctx)
{
ctx = apr_pcalloc(f->c->pool, sizeof(*ctx));
Re: mod_ssl hosed
On Thu, 15 Nov 2001, Ryan Bloom wrote: > Well, I found the problem. SSL is not a NETWORK filter. It is somewhere > between a CONNECTION and NETWORK filter. I have got a fix, but I am > still testing it. > > The reason it is not a NETWORK filter, is that SSL doesn't actually write to > the network. Some SSL filters will be NETWORK filters, but those will actually > take over the reading and writing. > > Commit within the hour. all good now, thanks!
Re: mod_ssl hosed
On Thu, 15 Nov 2001, Aaron Bannert wrote: > When was the last time you synch'd? I did some style changes yesterday, > but I was pretty careful not to change any functionality, but it's still > possible. i have those changes in my tree. i don't think it is mod_ssl that's actually broken, looks like the core filter is getting run before the ssl filter.
mod_ssl hosed
was working fine yesterday, just synced with cvs and all ssl tests hang here.. 0x401c91de in __select () from /lib/libc.so.6 (gdb) where #0 0x401c91de in __select () from /lib/libc.so.6 #1 0x40048490 in __DTOR_END__ () from /home/dougm/ap/prefork-shared/lib/libapr.so.0 #2 0x4003a4e0 in apr_recv (sock=0x824f8bc, buf=0xb570 "\025!D", len=0xb56c) at sendrecv.c:142 #3 0x8096318 in ap_lingering_close (dummy=0x824f98c) at connection.c:205 #4 0x40044fec in run_cleanups (c=0x824fc14) at apr_pools.c:833 #5 0x400451a2 in apr_pool_clear (a=0x824f88c) at apr_pools.c:949 #6 0x808ae72 in child_main (child_num_arg=0) at prefork.c:598 #7 0x808b0f4 in make_child (s=0x8172bcc, slot=0) at prefork.c:719 #8 0x808b235 in startup_children (number_to_start=1) at prefork.c:793 #9 0x808b5f0 in ap_mpm_run (_pconf=0x8171f2c, plog=0x81a20ac, s=0x8172bcc) at prefork.c:988 #10 0x8091212 in main (argc=8, argv=0xb964) at main.c:432 #11 0x40112b5c in __libc_start_main (main=0x8090cf4 , argc=8, ubp_av=0xb964, init=0x80714bc <_init>, fini=0x81361ec <_fini>, rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xb95c) at ../sysdeps/generic/libc-start.c:129 and requesting https://localhost:8530/ through netscape also hangs: 0x401c91de in __select () from /lib/libc.so.6 (gdb) where #0 0x401c91de in __select () from /lib/libc.so.6 #1 0x40048490 in __DTOR_END__ () from /home/dougm/ap/prefork-shared/lib/libapr.so.0 #2 0x4003a4e0 in apr_recv (sock=0x824f8bc, buf=0x827e308 "", len=0xbfffd64c) at sendrecv.c:142 #3 0x4001bb24 in socket_read (a=0x827e2e8, str=0xbfffd650, len=0xbfffd64c, block=APR_BLOCK_READ) at apr_buckets_socket.c:75 #4 0x809fe82 in core_input_filter (f=0x824fc2c, b=0x821162c, mode=AP_MODE_BLOCKING, readbytes=0xbfffd6a8) at core.c:2937 #5 0x8097bca in ap_get_brigade (next=0x824fc2c, bb=0x821162c, mode=AP_MODE_BLOCKING, readbytes=0xbfffd6a8) at util_filter.c:250 #6 0x8098ad2 in ap_getline (s=0xbfffd710 "\224Æ\e\bÄa\001@8×ÿ¿", n=8192, r=0x8210e54, fold=0) at protocol.c:224 #7 0x8098f62 in read_request_line (r=0x8210e54) at protocol.c:404 #8 0x80996b0 in ap_read_request (conn=0x824f99c) at protocol.c:585 #9 0x8084f0b in ap_process_http_connection (c=0x824f99c) at http_core.c:276 #10 0x8095fff in ap_run_process_connection (c=0x824f99c) at connection.c:83 #11 0x8096391 in ap_process_connection (c=0x824f99c) at connection.c:224 #12 0x808b04f in child_main (child_num_arg=0) at prefork.c:684 #13 0x808b0f4 in make_child (s=0x8172bcc, slot=0) at prefork.c:719 #14 0x808b235 in startup_children (number_to_start=1) at prefork.c:793 #15 0x808b5f0 in ap_mpm_run (_pconf=0x8171f2c, plog=0x81a20ac, s=0x8172bcc) at prefork.c:988 #16 0x8091212 in main (argc=8, argv=0xb964) at main.c:432 #17 0x40112b5c in __libc_start_main (main=0x8090cf4 , argc=8, ubp_av=0xb964, init=0x80714bc <_init>, fini=0x81361ec <_fini>, rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xb95c) at ../sysdeps/generic/libc-start.c:129
ap_cgi_var_lookup()
i would like to avoid calling ap_add_{common,cgi}_vars() in mod_perl and
just tie Perl's %ENV to a lookup function. i cooked up some generated
code based logic in Perl's ExtUtils::Constant module. the generated code
will probably explain itself better than i can, but here is a comment from
the gen_vars.pl script:
#the jist of this generated code is that we:
#do not want to build a hash table of 30-something entries
#do not want to do 30-something strcmps
#so what we do is this:
#call strlen() only once
#switch on length, then switch on optimal offset (name[offset])
#and memcmp (as few times as possible) with given length
#see comment in best_index() for detail
i put a proof-of-concept here:
http://httpd.apache.org/~dougm/mod_cgi_vars.tar.gz
reason i'm posting here is because the code could be used in
ssl_var_lookup() and the code generator could be extended to
deal with ssl-specific variables. ssl_var_lookup() is currently a big
hairball of strcmps. and the "30-something" in the comment above, is
quite a bit more than that for ssl_var_lookup().
