Ajax Problems - dynamic content not loading/showing - ISPConfig CP

[GoogleCodeExporter]

What version/revision number of mod_spdy are you using?
wget https://dl-ssl.google.com/dl/linux/direct/mod-spdy-beta_current_i386.deb

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

What other Apache modules are you using?  (Use `apache2ctl -M` to check.)
I will check as soon as I get home, I do not have server access here.
At least:
- mod_rewrite
- mod_evasine
- mod_security
- mod_pagespeed

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.)
Chrome 18.0.1025.163 on OSX 10.7

What steps will reproduce the problem?
1. Login into the ISPConfig CP

What is the expected result? What do you see instead?
The CP runs without problems on normal SSL, but not with activated mod_spdy. 
ISPConfig uses ajax technology to load the navigations (top-navigation as well 
as sidebar-navigation). Both do not appear on spdy.

Please provide any additional information below.
If you need a demo account to access the ISPConfig CP let me know. :)

Original issue reported on code.google.com by michel.k...@gmail.com on 24 Apr 2012 at 5:42

[GoogleCodeExporter]

Here are the loaded Apache modules:

core_module (static)
 log_config_module (static)
 logio_module (static)
 mpm_prefork_module (static)
 http_module (static)
 so_module (static)
 actions_module (shared)
 alias_module (shared)
 auth_basic_module (shared)
 auth_digest_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)
 dav_module (shared)
 dav_fs_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 expires_module (shared)
 fcgid_module (shared)
 headers_module (shared)
 include_module (shared)
 mime_module (shared)
 evasive20_module (shared)
 security2_module (shared)
 negotiation_module (shared)
 pagespeed_module (shared)
 php5_module (shared)
 reqtimeout_module (shared)
 rewrite_module (shared)
 ruby_module (shared)
 setenvif_module (shared)
 spdy_module (shared)
 ssl_module (shared)
 status_module (shared)
 suexec_module (shared)
 suphp_module (shared)
 unique_id_module (shared)

Original comment by michel.k...@gmail.com on 24 Apr 2012 at 5:18

[GoogleCodeExporter]

Me again. Same problem seems to encounter with RoundCube Webmail, reported 
here: http://www.howtoforge.com/forums/showpost.php?p=278260&postcount=4

Original comment by michel.k...@gmail.com on 27 Apr 2012 at 7:20

[GoogleCodeExporter]

Both RoundCube and ISPConfig are PHP applications.
Very likely your server(s) are running mod_php, rather than FastCGI (mod_fcgid).

As explained in the post below, there is an incompatability between mod_php and 
mod_spdy that can come about when doing simultaneous connections:

https://www.modspdy.com/blog/2012/04/15/using-mod_spdy-with-php

From my testing today I've realized that SPDY on mod_php works fine if you're 
just loading pages one at a time (which is what happens with Chrome on a SPDY 
connection), but if you're doing simultaneous things, like doing a POST while 
requesting another page, the SPDY session is interrupted and starts over. 

In my case, a custom image upload script wouldn't work, because every time a 
resource was loaded from the server, the upload POST would get interrupted and 
start over again.

Original comment by vanch...@gmail.com on 28 Apr 2012 at 10:00

[GoogleCodeExporter]

Indeed: mod_php tends to interact poorly with mod_spdy for the same reason that 
mod_php tends to interact poorly with the Apache Worker MPM.  You can solve the 
problem by configuring your server to serve PHP with mod_fcgid rather than with 
mod_php.  The above linked blog post explains how to do this; you can also find 
the same information here: https://developers.google.com/speed/spdy/mod_spdy/php

Original comment by mdste...@google.com on 2 May 2012 at 8:16

[GoogleCodeExporter]

Hey you two

Thank you both for your answers.

It's not that I am very happy with this, but if spdy does (and will?) not 
support mod_php I have to live with that situation :)

Regards,
Michel

Original comment by michel.k...@gmail.com on 3 May 2012 at 6:20

[GoogleCodeExporter]

It seems this was simply a case of mod_php/mod_spdy incompatibility (which, 
unfortunately, there's not much we can do about), so I'm going to go ahead and 
close this bug.  If you do switch to using mod_fcgid for PHP, and if you 
continue to have any issues with mod_spdy, please let me know and/or open a new 
bug.

Original comment by mdste...@google.com on 15 May 2012 at 2:24

• Changed state: WontFix

[GoogleCodeExporter]

I encountered very similar problem with nginx + Chrome.
have a look  http://trac.nginx.org/nginx/ticket/385 - detailed description 
available

in short, Chrome browser violates SPDY spec and sends empty header, which in 
turn make web server drop the connection.

Original comment by chipits...@gmail.com on 14 Aug 2013 at 5:34