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
