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

[GoogleCodeExporter]

The common way to force HTTP traffic over to HTTPS is to use mod_rewrite like 
so:

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

as described in e.g.:
http://www.cyberciti.biz/tips/howto-apache-force-https-secure-connections.html

See the mod_rewrite docs: 
http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritecond

The HTTPS variable is populated in mod_rewrite by calling the mod_ssl optional 
hook ssl_is_https, which returns false for any of the mod_spdy request handling 
threads.

The result is that web servers that use the above redirect pattern go into a 
redirect loop.

A mod_spdy-safe way to achieve the same redirect is:

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

but we should still fix this.

This is closely related to issue 31. As Matthew notes in that issue, "the SPDY 
stream requests are handled internally using "virtual" connections for which 
mod_ssl is disabled".

We'll need to think about perhaps leaving mod_ssl "enabled" but have it pass 
traffic through.

Alternatively, perhaps we can export an ssl_is_https function ourselves; not 
sure how that would work exactly and what the ordering is for which module 
would "win" when registering. So this seems quite fragile.

More thought needed.

Original issue reported on code.google.com by bmcqu...@google.com on 15 Apr 2012 at 10:57

[GoogleCodeExporter]

Original comment by bmcqu...@google.com 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 rpowers...@gmail.com 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 mdste...@google.com 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 rpowers...@gmail.com 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 stefan.r...@gmail.com 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 rpowers...@gmail.com 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 stefan.r...@gmail.com 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 basilgo...@gmail.com 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 johnde...@gmail.com 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 xynt...@gmail.com on 25 Jan 2014 at 5:04