httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Urp(!) - indeterminant connection SO_NONBLOCK state?
Date Fri, 30 Sep 2005 18:19:54 GMT
Linux, Win32 and Netware begin their new socket's life in a blocking
state, while Solaris and AIX begin their life in a non-blocking state.

You can observe the discrepancy (in 2.0.x, which happens to be what
I'm testing) by simply loading, and setting ProtocolEcho on
in the default SSL context.

Linux, Win32 and Netware successfully handshake an SSL echo port, while
Solaris and AIX read 'some bytes' and then die with a failed handshake.

mod_ftp.c has an ugly little hack in SSL mode initialization;

      * On SSL init, always set the socket to be initialized to
      * blocking to force SSL_accept() to complete without returning
      * SSL_WANT_READ.  Upon completion of this process, the original
      * socket block option is set.
     client_socket = ap_get_module_config(cdata->conn_config,
     rv = apr_socket_opt_get(client_socket, APR_SO_NONBLOCK, &block);
     rv = apr_socket_opt_set(client_socket, APR_SO_NONBLOCK, 0);
     bb = apr_brigade_create(cdata->pool, cdata->bucket_alloc);
     rv = ap_get_brigade(cdata->input_filters, bb, AP_MODE_INIT,
                         APR_BLOCK_READ, 0);
     rv = apr_socket_opt_set(client_socket, APR_SO_NONBLOCK, block);

(error messages omitted).  Now the AP_MODE_INIT is required, mod_ssl
requires an initial-read (remember ftp: - first thing you see is the
write-to-client of the Welcome message).

Do we want to;

  * Fix mod_echo with this gross little hack?  (and leave it to each
    protocol module author?)

  * Modify mod_ssl so that APR_BLOCK_READ actually toggles the socket
    to blocking mode (or keeps reinvoking the core until it gets the
    bytes that SSL demands)?

  * Modify the core so that APR_BLOCK_READ actually toggles the socket
    blocking mode?

  * Modify the MPM such that the newly accept()ed socket is toggled
    into blocking mode?

  * Modify APR such that a newly created socket's state is of some
    known value?  (Right now, it pretends that it knows if the platform
    has predetermined that the accept()ed socket's state is inherited
    from the listening socket - and Linux's state proves this assumption
    was invalid.)



View raw message