#2 0x8091753 in ssl_io_filter_input (f=0x825d760, bb=0x825f440, mode=AP_MODE_GETLINE, block=APR_BLOCK_READ,
readbytes=0) at ssl_engine_io.c:1231
1231 if ((status = ssl_io_filter_connect(inctx->filter_ctx)) != APR_SUCCESS) {
(gdb) p inctx->filter_ctx $1 = (ssl_filter_ctx_t *) 0x0
I haven't tried very hard to see how inctx->filter_ctx can get cleared, but first I wonder about the big picture: Is continued I/O reasonabe after the negotiation failure? It *seems* like the clients I'm playing with (wget, Mozilla) have given up at that point anyway.
If it isn't reasonable, then c->aborted should be set.
This is very closely related to PR 21370, where the reporter has a few extra lines in his patch which I did not need.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21370
(If there is anything good about this patch, the reporter is responsible. If anything bad, he is completely innocent.)
Index: modules/ssl/ssl_engine_kernel.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_kernel.c,v
retrieving revision 1.82.2.6
diff -u -r1.82.2.6 ssl_engine_kernel.c
--- modules/ssl/ssl_engine_kernel.c 16 May 2003 18:12:18 -0000 1.82.2.6
+++ modules/ssl/ssl_engine_kernel.c 16 Jul 2003 15:10:48 -0000
@@ -696,6 +696,7 @@
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
"Re-negotiation request failed");
+ r->connection->aborted = 1;
return HTTP_FORBIDDEN;
}@@ -710,6 +711,7 @@
"Re-negotiation handshake failed: "
"Not accepted by client!?");+ r->connection->aborted = 1;
return HTTP_FORBIDDEN;
}
}