mod_spdy Breaks Apache Error Pages

[GoogleCodeExporter]

What version/revision number of mod_spdy are you using?

0.9.3.3

What version of Apache are you using, and on what operating system?  (Use
`apache2ctl -v` to check.)

Apache/2.2.22 (Ubuntu)

What other Apache modules are you using?  (Use `apache2ctl -M` to check.)

 core_module (static)
 log_config_module (static)
 logio_module (static)
 mpm_prefork_module (static)
 http_module (static)
 so_module (static)
 alias_module (shared)
 auth_basic_module (shared)
 authn_file_module (shared)
 authz_default_module (shared)
 authz_groupfile_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 cgi_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 mime_module (shared)
 negotiation_module (shared)
 php5_module (shared)
 reqtimeout_module (shared)
 setenvif_module (shared)
 spdy_module (shared)
 ssl_module (shared)
 status_module (shared)
 uwsgi_module (shared)

What browser version did you use to access the mod_spdy server?  On what
operating system? What flags was the browser invoked with?  (For
Chrome/Chromium, go to about:version to check.)

Multiple browsers, multiple operating systems, multiple versions. At minimum 
Chrome and Firefox on both Linux and Mac OS X.

What steps will reproduce the problem?
No special configuration; just have a proxy or other CGI script return a HTTP 
500.

What is the expected result? What do you see instead?
The expected result is an error page, either the Apache default or a configured 
page.

The result I see is that mod_spdy fails to respond to the browser, resulting in 
the connection apparently hanging forever.

Please provide any additional information below.

Original issue reported on code.google.com by npi...@lexmachina.com on 11 Dec 2012 at 10:40

[GoogleCodeExporter]

Hi, thanks very much for the report.  I am having trouble reproducing the 
problem: I set up a quick test server with the latest version of mod_spdy and a 
simple Python CGI script that produces an HTTP 500 by calling sys.exit(1), and 
the default Apache error page shows up just fine for me via SPDY (using Chrome 
24 on Linux).

I notice that you have mod_php enabled, which doesn't always play nice with 
mod_spdy (for the same reason that mod_php doesn't always play nice with 
mpm_worker).  Is it possible that that is the source of the problem?  I would 
recommend following the instructions here for setting up PHP to work safely 
with mod_spdy, if only to rule that out as a possible issue: 
https://developers.google.com/speed/spdy/mod_spdy/php

If the problem still persists after disabling mod_php5, then can you give me 
more information about your setup?  What precise method are you using to 
produce the 500?  Does the error page show up fine over plain HTTP?  How about 
plain HTTPS (with mod_spdy disabled)?

Original comment by mdste...@google.com on 13 Dec 2012 at 5:27

• Changed state: MoreInfo

[GoogleCodeExporter]

We're using mod_uwsgi with a WSGI application. With mod_spdy disabled, the 
apache error page is served just fine. The problem appears to be mod_spdy's 
handling of a 0 byte HTTP error reply returned by mod_uwsgi. Further debugging 
and logging efforts revealed output along the lines of:

[Tue Dec 11 14:54:22 2012] [debug] mod_spdy/apache/log_message_handler.cc(106): 
[client 50.0.77.3] [mod_spdy/0.9.3.3-386] 
[14731:14731:VERBOSE2:spdy_session.cc(458)] Received SYN_STREAM; opening stream 
1
[Tue Dec 11 14:54:22 2012] [debug] mod_spdy/apache/log_message_handler.cc(106): 
[client 50.0.77.3] [mod_spdy/0.9.3.3-386] 
[14731:14731:VERBOSE4:spdy_session.cc(323)] [stream 1] Received DATA (length=0)
[Tue Dec 11 14:54:22 2012] [debug] mod_spdy/apache/log_message_handler.cc(120): 
[client 50.0.77.3] [stream 1] [mod_spdy/0.9.3.3-386] 
[14731:14735:VERBOSE3:apache_spdy_stream_task_factory.cc(121)] Starting stream 
task
[Tue Dec 11 14:54:22 2012] [debug] ssl_engine_io.c(1931): OpenSSL: I/O error, 5 
bytes expected to read on BIO#7f18ef5928e0 [mem: 7f18ef583303]
[Tue Dec 11 14:54:22 2012] [debug] ssl_engine_io.c(1931): OpenSSL: I/O error, 5 
bytes expected to read on BIO#7f18ef5928e0 [mem: 7f18ef583303]
[Tue Dec 11 14:54:22 2012] [debug] ssl_engine_io.c(1931): OpenSSL: I/O error, 5 
bytes expected to read on BIO#7f18ef5928e0 [mem: 7f18ef583303]
[Tue Dec 11 14:54:22 2012] [debug] ssl_engine_io.c(1931): OpenSSL: I/O error, 5 
bytes expected to read on BIO#7f18ef5928e0 [mem: 7f18ef583303]
[Tue Dec 11 14:54:22 2012] [debug] ssl_engine_io.c(1931): OpenSSL: I/O error, 5 
bytes expected to read on BIO#7f18ef5928e0 [mem: 7f18ef583303]
[Tue Dec 11 14:54:22 2012] [debug] ssl_engine_io.c(1931): OpenSSL: I/O error, 5 
bytes expected to read on BIO#7f18ef5928e0 [mem: 7f18ef583303]
[Tue Dec 11 14:54:22 2012] [debug] ssl_engine_io.c(1931): OpenSSL: I/O error, 5 
bytes expected to read on BIO#7f18ef5928e0 [mem: 7f18ef583303]
[Tue Dec 11 14:54:22 2012] [debug] ssl_engine_io.c(1931): OpenSSL: I/O error, 5 
bytes expected to read on BIO#7f18ef5928e0 [mem: 7f18ef583303]
[Tue Dec 11 14:54:23 2012] [debug] ssl_engine_io.c(1931): OpenSSL: I/O error, 5 
bytes expected to read on BIO#7f18ef5928e0 [mem: 7f18ef583303]
[Tue Dec 11 14:54:23 2012] [debug] ssl_engine_io.c(1931): OpenSSL: I/O error, 5 
bytes expected to read on BIO#7f18ef5928e0 [mem: 7f18ef583303]
[Tue Dec 11 14:54:23 2012] [debug] ssl_engine_io.c(1931): OpenSSL: I/O error, 5 
bytes expected to read on BIO#7f18ef5928e0 [mem: 7f18ef583303]
[Tue Dec 11 14:54:23 2012] [debug] ssl_engine_io.c(1931): OpenSSL: I/O error, 5 
bytes expected to read on BIO#7f18ef5928e0 [mem: 7f18ef583303]
[Tue Dec 11 14:54:23 2012] [debug] ssl_engine_io.c(1931): OpenSSL: I/O error, 5 
bytes expected to read on BIO#7f18ef5928e0 [mem: 7f18ef583303]
[Tue Dec 11 14:54:23 2012] [debug] ssl_engine_io.c(1931): OpenSSL: I/O error, 5 
bytes expected to read on BIO#7f18ef5928e0 [mem: 7f18ef583303]

Original comment by npi...@lexmachina.com on 13 Dec 2012 at 6:50