httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: svn commit: r327945 - in /httpd/httpd/trunk: CHANGES modules/http/http_core.c modules/http/http_request.c server/mpm/experimental/event/event.c
Date Wed, 26 Oct 2005 16:34:40 GMT
Brian Pane wrote:
> It looks like the new core output filter is messing up the blocking mode
> when it's called during the sending of the request to the origin server.
> I'll continue tracking this down tomorrow.

Messing it up?  Or failing to set it up?

proxy_util.c invokes create_connection (which has some double-close socket
issues, if you follow the hook providers and then observe that we close the
socket locally in the proxy_util.c ap_proxy_connection_create).  When it
then runs the pre_connection hook, the initial blocking/timeout state is
set up correctly.

However, proxy_http (and possibly proxy_connect) fails to include the following
code fragment after invoking ap_proxy_connection_create();

         bb = apr_brigade_create(cdata->pool, cdata->bucket_alloc);
         rv = ap_get_brigade(cdata->input_filters, bb, AP_MODE_INIT,
                             APR_BLOCK_READ, 0);

         if (rv != APR_SUCCESS) {
             ap_log_error(APLOG_MARK, APLOG_ERR, rv, cdata->base_server,
                          "Failed to initialize the proxy ssl data stream");
             goto cleanup;

so if the backend proxy connection is SSL, and we attempt to write before
we read (at least, that's http:) then the handshake isn't properly invoked.

I have to study proxy_connect to determine that we do a speculative read before
we attempt to write, such that we would always handshake SSL/TLS.


View raw message