DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=43738>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43738 Summary: Who is hiding my buffered POST data from mod_ssl after renegotiation? Product: Apache httpd-2 Version: 2.2.3 Platform: All OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: mod_ssl AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] These logs show a connection to a FastCGI server in a directory which requires SSL renegotiation. mod_fastcgi uses the deprecated ap_get_client_block() family to read POST data from the client, but rewriting it to use the underlying Apache 2 APIs shows identical results. I've deleted a few lines that aren't relevant to this analysis... [Tue Oct 30 16:41:47 2007] [info] [client 128.30.28.20] Connection to child 9 established (server courses.csail.mit.edu:443) ... [Tue Oct 30 16:41:47 2007] [debug] ssl_engine_io.c(1478): [client 128.30.28.20] filling buffer [Tue Oct 30 16:41:47 2007] [debug] ssl_engine_io.c(1529): [client 128.30.28.20] total of 525 bytes in buffer, eos=1 ...my analysis concentrates here... [Tue Oct 30 16:42:21 2007] [error] [client 128.30.28.20] FastCGI: comm with server "/usr/bin/php5-cgi" aborted: idle timeout (30 sec), referer: [URI deleted] [Tue Oct 30 16:42:21 2007] [debug] ssl_engine_io.c(1561): [client 128.30.28.20] read from buffered SSL brigade, mode 0, 8192 bytes [Tue Oct 30 16:42:21 2007] [debug] ssl_engine_io.c(1623): [client 128.30.28.20] buffered SSL brigade now exhausted; removing filter The reason for the timeout is that the FastCGI server is waiting to read POST data from the server which never arrives. In fact, the server thinks it should be passing client data, but when ap_get_client_block() attempts to read the client data, it gets an EOS. More interestingly, an examination of the input_filter chain at that point shows "http_in" followed by "ssl/tls filter"; I believe the second (or maybe the first) filter here should be "ssl/tls buffer" instead. (We know from the two previous lines that the POST content has been successfully buffered.) The buffer does eventually get read, as the following log entries show -- but not by mod_fastcgi. The very last thing that ssl_io_buffer_fill() does is add the "ssl/tls buffer" filter, so I don't understand why it doesn't appear at the head of the input filter list when ap_get_client_block() is running, nor why it does get read (and presumably is in the filter chain) after the request is aborted. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
