Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <3D051F25.5020106@remulak.net>
Date: Mon, 10 Jun 2002 17:50:29 -0400
From: "Paul J. Reder" <rederpj@remulak.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901
MIME-Version: 1.0
To: "Apache Dev." <dev@httpd.apache.org>
Subject: Recursive error processing.
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

While Allan Edwards and I were doing some testing of SSL we ran into a case
where we were able to send Apache into an infinite loop which eventually
consumed the machine's resources.

The problem occurs if you send a request to "http://some.where.com:443" (instead
of "https://some.where.com:443".

Apache tries to return a custom error but gets confused while trying to
send the error response to a non-secure request over an apparently secure
connection.

A small snip of the back trace follows:

#590 0x080a1549 in ap_die (type=400, r=0x81e0e58) at http_request.c:198
#591 0x080a1b51 in internal_internal_redirect (new_uri=0x8188770 "/error/HTTP_BAD_REQUEST.html.var", r=0x81e0650) at http_request.c:408
#592 0x080a1e10 in ap_internal_redirect (new_uri=0x8188770 "/error/HTTP_BAD_REQUEST.html.var", r=0x81e0650) at http_request.c:483
#593 0x080a1549 in ap_die (type=400, r=0x81e0650) at http_request.c:198
#594 0x080a1b51 in internal_internal_redirect (new_uri=0x8188770 "/error/HTTP_BAD_REQUEST.html.var", r=0x81df1c0) at http_request.c:408
#595 0x080a1e10 in ap_internal_redirect (new_uri=0x8188770 "/error/HTTP_BAD_REQUEST.html.var", r=0x81df1c0) at http_request.c:483
#596 0x080a1549 in ap_die (type=400, r=0x81df1c0) at http_request.c:198
#597 0x080e4c24 in ap_read_request (conn=0x81cce58) at protocol.c:982
#598 0x0809bc63 in ap_process_http_connection (c=0x81cce58) at http_core.c:284
#599 0x080dfc17 in ap_run_process_connection (c=0x81cce58) at connection.c:85
#600 0x080dffbe in ap_process_connection (c=0x81cce58, csd=0x81ccd88) at connection.c:207
#601 0x080d2123 in child_main (child_num_arg=0) at prefork.c:671
#602 0x080d21f4 in make_child (s=0x8132908, slot=0) at prefork.c:711
---Type <return> to continue, or q <return> to quit---
#603 0x080d2321 in startup_children (number_to_start=5) at prefork.c:783
#604 0x080d274b in ap_mpm_run (_pconf=0x812e9f0, plog=0x8172b00, s=0x8132908) at prefork.c:999
#605 0x080d8e98 in main (argc=5, argv=0xbffff884) at main.c:646
#606 0x402be627 in __libc_start_main (main=0x80d8600 <main>, argc=5, ubp_av=0xbffff884, init=0x80658f0 <_init>, fini=0x80f81e0 <_fini>, 
rtld_fini=0x4000dcc4 <_dl_fini>,
     stack_end=0xbffff87c) at ../sysdeps/generic/libc-start.c:129

The loop (ap_die, ap_internal_redirect, internal_internal_redirect, ap_die...) happens
until the system dies (due to newly allocated request_recs).

The problem seems to be related to the fact that ap_die should be killing
the custom_response and just dropping the connection (which is what 1.3 does)
rather than falling through and trying to send a custom response via internal_redirect.

Is this an artifact of the recent changes for 401/413 processing? Is this symptomatic
of a bigger problem of infinite loops during error redirects?

This all starts because the SSL post_read_request hook function (ssl_hook_ReadReq)
returns HTTP_BAD_REQUEST after finding sslconn->non_ssl_request set to 1 (by
ssl_io_filter_input after it notices ssl_connect fails in ssl_hook_process_connection).

Thanks for any pointers here.

-- 
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein