RE: [PATCH-Modified-2] SSL not sending close alert message
Since I didn't receive any negative comments, I'll check it in.
-Madhu
-Original Message-
From: Mathihalli, Madhusudan
Sent: Thursday, February 26, 2004 11:58 AM
To: [EMAIL PROTECTED]
Subject: RE: [PATCH-Modified-2] SSL not sending close alert message
Sorry - the earlier mail was a result of my mis-understanding
Joe's comment. Here's the correct patch.
Thanks
-Madhu
Index: include/http_connection.h
===
RCS file: /home/cvs/httpd-2.0/include/http_connection.h,v
retrieving revision 1.59
diff -u -r1.59 http_connection.h
--- include/http_connection.h 9 Feb 2004 20:38:21 - 1.59
+++ include/http_connection.h 26 Feb 2004 17:54:32 -
@@ -103,6 +103,34 @@
*/
AP_DECLARE_HOOK(int,process_connection,(conn_rec *c))
+/* End Of Connection (EOC) bucket */
+
+AP_DECLARE_DATA extern const apr_bucket_type_t ap_bucket_type_eoc;
+
+/**
+ * Determine if a bucket is an End Of Connection (EOC) bucket
+ * @param e The bucket to inspect
+ * @return true or false
+ */
+#define AP_BUCKET_IS_EOC(e) (e->type == &ap_bucket_type_eoc)
+
+/**
+ * Make the bucket passed in an End Of Connection (EOC) bucket
+ * @param b The bucket to make into an EOC bucket
+ * @return The new bucket, or NULL if allocation failed
+ * @deffunc apr_bucket *ap_bucket_eoc_make(apr_bucket *b)
+ */
+AP_DECLARE(apr_bucket *) ap_bucket_eoc_make(apr_bucket *b);
+
+/**
+ * Create a bucket referring to an End Of Connection (EOC).
This indicates
+ * that the connection will be closed.
+ * @param list The freelist from which this bucket should be allocated
+ * @return The new bucket, or NULL if allocation failed
+ * @deffunc apr_bucket *ap_bucket_eoc_create(apr_bucket_alloc_t *list)
+ */
+AP_DECLARE(apr_bucket *)
ap_bucket_eoc_create(apr_bucket_alloc_t *list);
+
#ifdef __cplusplus
}
#endif
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_io.c,v
retrieving revision 1.118
diff -u -r1.118 ssl_engine_io.c
--- modules/ssl/ssl_engine_io.c 25 Feb 2004 10:54:29 - 1.118
+++ modules/ssl/ssl_engine_io.c 26 Feb 2004 17:54:33 -
@@ -100,6 +100,7 @@
BIO*pbioWrite;
ap_filter_t*pInputFilter;
ap_filter_t*pOutputFilter;
+intnobuffer; /* non-zero to prevent buffering */
} ssl_filter_ctx_t;
typedef struct {
@@ -193,7 +194,8 @@
*/
BIO_clear_retry_flags(bio);
-if (!outctx->length && (inl + outctx->blen <
sizeof(outctx->buffer))) {
+if (!outctx->length && (inl + outctx->blen <
sizeof(outctx->buffer)) &&
+!outctx->filter_ctx->nobuffer) {
/* the first two SSL_writes (of 1024 and 261 bytes)
* need to be in the same packet (vec[0].iov_base)
*/
@@ -1395,6 +1397,22 @@
*/
apr_bucket_delete(bucket);
}
+}
+else if (AP_BUCKET_IS_EOC(bucket)) {
+/* The special "EOC" bucket means a shutdown is needed;
+ * - turn off buffering in bio_filter_out_write
+ * - issue the SSL_shutdown
+ */
+filter_ctx->nobuffer = 1;
+status = ssl_filter_io_shutdown(filter_ctx, f->c, 0);
+if (status != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_INFO, status, NULL,
+ "SSL filter error shutting down I/O");
+}
+if ((status = ap_pass_brigade(f->next, bb)) !=
APR_SUCCESS) {
+return status;
+}
+break;
}
else {
/* filter output */
Index: server/Makefile.in
===
RCS file: /home/cvs/httpd-2.0/server/Makefile.in,v
retrieving revision 1.91
diff -u -r1.91 Makefile.in
--- server/Makefile.in 2 Feb 2004 17:04:10 - 1.91
+++ server/Makefile.in 26 Feb 2004 17:54:33 -
@@ -13,7 +13,8 @@
connection.c listen.c \
mpm_common.c util_charset.c util_debug.c util_xml.c \
util_filter.c exports.c buildmark.c \
- scoreboard.c error_bucket.c protocol.c core.c request.c
provider.c
+ scoreboard.c error_bucket.c protocol.c core.c request.c
provider.c \
+ eoc_bucket.c
TARGETS = delete-exports $(LTLIBRARY_NAME) $(CORE_IMPLIB_FILE)
export_vars.h httpd.exp
Index: server/connection.c
===
RCS file: /home/cvs/httpd-2.0/server/connection.c,v
retrieving revision 1.114
diff -u -r1.114 connection.c
--- connection.c9 Feb 2004 20:40:49 - 1.114
+++ connection.c26 Feb 2004 19:55:49 -
@@ -71,8 +71,15 @@
apr_bucket *b;
bb = apr_brigade_create(c->pool, c->bucket_alloc);
+
+/* FLUSH bucket */
b = apr_bucket_flush_create(c->bucket_alloc);
APR_BRIGADE_INSERT_TAIL(bb, b);
+
+/* End Of Connection bucket */
+b = apr_bucket_eoc_crea
Re: piped logger fixes and 2.0.49 and Windows
Justin Erenkrantz wrote: --On Friday, February 27, 2004 6:01 AM -0500 Jeff Trawick <[EMAIL PROTECTED]> wrote: Is it reasonable to commit the piped logger stuff without the Win32/BeOS/OS/2 support? I think yes, even though that will result in crashing piped loggers not being restarted on those platforms until the platform maintainers get a chance to work through the MPM changes. But if anyone is going to consider such a regression a SHOWSTOPPER later for getting 2.0.49 out the door, then this would be a bad move. Thoughts? How hard would it be to guess what needs to happen in those MPMs? I bet OtherBill can quickly look at the Win32 patch and cast the 3rd +1 when he gets to it. ake stepped up to the Win32 task. But, for BeOS and OS/2, can we just put something in if their maintainers aren't getting to it? Or is it better to do nothing? If we do nothing, the error log should have "can't query MPM state; not restarting piped log program 'foo'" which should be a big enough clue.
Re: piped logger fixes and 2.0.49 and Windows
--On Friday, February 27, 2004 6:01 AM -0500 Jeff Trawick <[EMAIL PROTECTED]> wrote: Is it reasonable to commit the piped logger stuff without the Win32/BeOS/OS/2 support? I think yes, even though that will result in crashing piped loggers not being restarted on those platforms until the platform maintainers get a chance to work through the MPM changes. But if anyone is going to consider such a regression a SHOWSTOPPER later for getting 2.0.49 out the door, then this would be a bad move. Thoughts? How hard would it be to guess what needs to happen in those MPMs? I bet OtherBill can quickly look at the Win32 patch and cast the 3rd +1 when he gets to it. But, for BeOS and OS/2, can we just put something in if their maintainers aren't getting to it? Or is it better to do nothing? -- justin
Re: [PATCH] Windows IPv6
William A. Rowe, Jr. wrote:
+1, but which warning does 4163 quiet?
It quiets "C4163: '_rotl64' : not available as an intrinsic
function'" (see below) that gets generated as a result of
including the platform SDK. Picking up the platform SDK also
results in a couple of other warnings but this was the
major offendor.
Allan
At 09:46 AM 2/26/2004, you wrote:
Here's a patch to enable IPv6 on Windows XP & 2003.
In addition we'll need to change the setting of
APR_HAVE_IPV6 in apr.hw - seems like we'll need
some awk magic to do that.
Note that enabling IPv6 drags in the need for
the XP or 2003 platform SDK but I don't see
any way around it. I believe the platform SDK can
be freely downloaded from MS for those who want to
do an IPv6 build.
Any comments before I commit to 2.1?
Allan
Index: server/mpm/winnt/child.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/winnt/child.c,v
retrieving revision 1.26
diff -u -d -b -r1.26 child.c
--- server/mpm/winnt/child.c9 Feb 2004 20:40:51 -1.26
+++ server/mpm/winnt/child.c25 Feb 2004 16:20:51 -
@@ -314,13 +314,17 @@
int wait_time = 1;
int csd;
SOCKET nsd = INVALID_SOCKET;
-struct sockaddr_in sa_client;
int count_select_errors = 0;
int rc;
int clen;
ap_listen_rec *lr;
struct fd_set listenfds;
SOCKET listenmaxfd = INVALID_SOCKET;
+#if APR_HAVE_IPV6
+struct sockaddr_in6 sa_client;
+#else
+struct sockaddr_in sa_client;
+#endif
/* Setup the listeners
* ToDo: Use apr_poll()
@@ -395,7 +399,13 @@
static PCOMP_CONTEXT win9x_get_connection(PCOMP_CONTEXT context)
{
apr_os_sock_info_t sockinfo;
-int len;
+int len, salen;
+#if APR_HAVE_IPV6
+salen = sizeof(struct sockaddr_in6);
+#else
+salen = sizeof(struct sockaddr_in);
+#endif
+
if (context == NULL) {
/* allocate the completion context and the transaction pool */
@@ -415,7 +425,7 @@
if (context->accept_socket == INVALID_SOCKET) {
return NULL;
}
-len = sizeof(struct sockaddr);
+len = salen;
context->sa_server = apr_palloc(context->ptrans, len);
if (getsockname(context->accept_socket,
context->sa_server, &len)== SOCKET_ERROR) {
@@ -423,7 +433,7 @@
"getsockname failed");
continue;
}
-len = sizeof(struct sockaddr);
+len = salen;
context->sa_client = apr_palloc(context->ptrans, len);
if ((getpeername(context->accept_socket,
context->sa_client, &len)) == SOCKET_ERROR) {
@@ -434,7 +444,7 @@
sockinfo.os_sock = &context->accept_socket;
sockinfo.local = context->sa_server;
sockinfo.remote = context->sa_client;
-sockinfo.family = APR_INET;
+sockinfo.family = context->sa_server->sa_family;
sockinfo.type= SOCK_STREAM;
apr_os_sock_make(&context->sock, &sockinfo, context->ptrans);
@@ -465,9 +475,21 @@
DWORD BytesRead;
SOCKET nlsd;
int rv, err_count = 0;
+#if APR_HAVE_IPV6
+SOCKADDR_STORAGE ss_listen;
+int namelen = sizeof(ss_listen);
+#endif
apr_os_sock_get(&nlsd, lr->sd);
+#if APR_HAVE_IPV6
+if (getsockname(nlsd, (struct sockaddr *)&ss_listen, &namelen) == SOCKET_ERROR) {
+ap_log_error(APLOG_MARK,APLOG_ERR, apr_get_netos_error(), ap_server_conf,
+"winnt_accept: getsockname error on listening socket, is IPv6
available?");
+return;
+ }
+#endif
+
while (!shutdown_in_progress) {
if (!context) {
context = mpm_get_completion_context();
@@ -479,6 +501,25 @@
}
/* Create and initialize the accept socket */
+#if APR_HAVE_IPV6
+if (context->accept_socket == INVALID_SOCKET) {
+context->accept_socket = socket(ss_listen.ss_family, SOCK_STREAM,
IPPROTO_TCP);
+context->socket_family = ss_listen.ss_family;
+}
+else if (context->socket_family != ss_listen.ss_family) {
+closesocket(context->accept_socket);
+context->accept_socket = socket(ss_listen.ss_family, SOCK_STREAM,
IPPROTO_TCP);
+context->socket_family = ss_listen.ss_family;
+}
+
+if (context->accept_socket == INVALID_SOCKET) {
+ap_log_error(APLOG_MARK,APLOG_WARNING, apr_get_netos_error(),
ap_server_conf,
+ "winnt_accept: Failed to allocate an accept socket. "
+ "Temporary resource constraint? Try again.");
+Sleep(100);
+continue;
+}
+#else
if (context->accept_socket == INVALID_SOCKET) {
context->accept_socket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if (context->accept_socket == INVALID_SOCKET) {
@@ -490,7 +531,7 @@
continue;
}
}
-
+#endif
/* AcceptEx on the completion context. The completion context will be
* signaled when a connection is accepted.
*/
@@
-D name command-line option on Win32
What is the correct syntax for the "-D name" command-line option on Win32 (and, indeed, other platforms too)? Specifically, should there be a space between the "-D" and the "name" or not? The reason I ask is that I've been having problems with the Perl Apache-Test module. On Win32 it starts up the server in single-process mode (-X) to make killing the process later easier, but it also used a "-DAPACHE1" option: apache.exe -DAPACHE1 -X I found that under Apache/1.3.29 the -X was being ignored and two processes (parent + child) got started, which then lead to one being left behind after the tests have finished. Inserting a space between the "-D" and the "APACHE1" fixed the problem. Apache/2.0.48 doesn't seem to have this problem. The output from "apache.exe -h" in both 1.3.29 and 2.0.48 shows a space: Usage: apache [-D name] [-d directory] [-f file] [-n service] [-C "directive"] [-c "directive"] [-k signal] [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T] -D name : define a name for use in directives [...] but Stas Bekman over on [EMAIL PROTECTED] prefers not having a space, because "-Dname" is in line with typical C compilers' behaviour. Hopefully the patch that I sent to [EMAIL PROTECTED] to insert the spaces will be kept since it seems to be required for 1.3.29 on Win32 (at least) and doesn't break anything else, but I just wondered whether requiring the space was intentional or a bug? Cheers, - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
piped logger fixes and 2.0.49 and Windows
The piped logger fixes themselves have been approved for backport. * piped log programs respawning after Apache is stopped. PR 24805 bogus "piped log program '(null)' failed" messages during restart. PR 21648. Two people have tested a similar log.c patch and the worker.c patch and given feedback in PR 24805. server/log.c r1.137 PREREQ: ap_mpm_query(mpm-state) support in MPMs (If an MPM is used that doesn't support the query, a complaint will be written to the error log when a piped log program terminates, and it won't get restarted.) +1: trawick, jerenkrantz, nd However, there is a regression on Win32, BeOS, and OS/2 until/unless those MPMs implement the mpm-state-query function. * PREREQ for another fix (stranded piped logger processes) - ap_mpm_query(AP_MPMQ_MPM_STATE) No updates are available at present for the BeOS or OS/2 MPMs, but that is not a showstopper for the other changes. server/mpm/winnt/mpm_winnt.c r1.303, r1.306 server/mpm/winnt/mpm_winnt.h r1.44 server/mpm/winnt/child.c r1.21 +1: trawick, stoddard Meanwhile, I've had a couple of people asking me for the code privately, so I'm anxious to get this in 2.0.49 and be done with it. Is it reasonable to commit the piped logger stuff without the Win32/BeOS/OS/2 support? I think yes, even though that will result in crashing piped loggers not being restarted on those platforms until the platform maintainers get a chance to work through the MPM changes. But if anyone is going to consider such a regression a SHOWSTOPPER later for getting 2.0.49 out the door, then this would be a bad move. Thoughts?
RE: Error in rcs file in httpd-2.0 CVS repository
On Fri, 2004-02-27 at 07:07, Sung Kim wrote: > > On Thu, 2004-02-26 at 11:17, Sander Striker wrote: > > From: Brian. W. Fitzpatrick [mailto:[EMAIL PROTECTED] > > Sent: Thursday, February 26, 2004 5:53 PM > > I'm in the process of testing out the cvs2svn.py converter, and the > > converter found an inconsistency in the httpd-2.0 repository. > > Is that mean the Apache httpd project going to use Subversion instead of CVS > soon? Don't know about soon, but we are looking into it. Sander
