mod_rewrite 'HTTPS' server variable doesn't return proper value when using mod_spdy

[uikit0]

mod_rewrite 'HTTPS' server variable doesn't return proper value when using mod_spdy

[GoogleCodeExporter]

Original comment by [email protected] on 16 Apr 2012 at 10:00

• Added labels: SSL

[GoogleCodeExporter]

I installed mod_spdy yesterday and am getting redirect loops. Direct requests 
to HTTPS URLs work, but HTTP requests which 302 redirect to HTTPS go into a 
redirect loop. Strangely enough, when I plug Fiddler in the redirect works (no 
loop).  The 302 is done by the web application using:

response.sendRedirect(uri.toString());

Chrome 18.0.1025.162 (Official Build 131933) m

Original comment by [email protected] on 18 Apr 2012 at 1:45

[GoogleCodeExporter]

Yes, I suspect this is the same sort of issue as above: if you redirect from 
HTTP to HTTPS, and the HTTPS url is served via mod_spdy, the handler may be 
misled into thinking the url served over SPDY is not being served over SSL, so 
it tries to redirect again.  Not sure why the problem disappears when you use 
Fiddler, though.

Can you tell me a little more about the web app that's doing the redirection?  
What language/framework is it written in, and what mechanism is it using to 
determine if the request is HTTP or HTTPS?

Original comment by [email protected] on 18 Apr 2012 at 3:10

[GoogleCodeExporter]

The app uses Struts2 (Java) with the SSL-plugin. The intercept method in the 
source file below handles the HTTPS redirection:

 http://struts2-ssl-plugin.googlecode.com/svn/trunk/plugin/src/main/java/com/googlecode/sslplugin/interceptors/SSLInterceptor.java

Original comment by [email protected] on 18 Apr 2012 at 5:55

[GoogleCodeExporter]

I have a similar issue when mod_spdy is combined with mod_proxy_ajp to forwared 
requests from Apache httpd to Tomcat. With SPDY enabled the scheme reported via 
AJP and the port are wrong (http instead of https and 80 instead of 443).

Original comment by [email protected] on 19 Apr 2012 at 11:40

[GoogleCodeExporter]

I also have an Apache/Tomcat setup with mod_proxy_ajp as described in comment 
#5.

Original comment by [email protected] on 19 Apr 2012 at 2:42

[GoogleCodeExporter]

As a workaround you can override the values by setting the scheme and proxyPort 
attributes on the connector:

<Connector port="8009" protocol="org.apache.coyote.ajp.AjpNioProtocol"
  URIEncoding="UTF-8" scheme="https" proxyPort="443"/>

Original comment by [email protected] on 19 Apr 2012 at 9:21

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I can confirm I had this same issue and that the workaround using the port 
number rather than the HTTPS flag does temporarily resolve the issue.  I do do 
a combination test, though, to have it at least catch another case, which is 
this:

        RewriteEngine   On
        RewriteCond     %{HTTPS}        off
        RewriteCond     %{SERVER_PORT}  ^80$
        RewriteRule     (.*)    https://%{HTTP_HOST}%{REQUEST_URI}

I check for both HTTPS being off as well as the port being 80, just to be safe, 
though either one alone should be fine, I suppose.

Original comment by [email protected] on 22 May 2012 at 5:41

[GoogleCodeExporter]

Same issue here on Debian stable, fixed with (ugly) workaround. Apart from 
that, works quite nicely! This is a last step to get it working out of the box 
on (my) standard setup.

Original comment by [email protected] on 19 Jul 2012 at 4:36

[GoogleCodeExporter]

This is still an issue as of:
mod-spdy-beta-0.9.4.1-397.x86_64

When using rewrite rule:
  RewriteEngine On
  RewriteCond ${SERVER_PROD} ^80$
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}


We are unable to roll out mod_spdy to all of our servers until this is fixed, 
because it will cause a significant amount of pain for customers.

Original comment by [email protected] on 25 Jan 2014 at 5:04