<div dir="ltr">Was a bit too quick with example, meant the 443 server does not have such a rewrite, that would mean a loop.<div><br></div><div><div style="font-family:arial,sans-serif;font-size:13px">server {</div><div style="font-family:arial,sans-serif;font-size:13px">

<div>       listen <a href="http://1.2.3.4:443/" target="_blank">1.2.3.4:443</a> ssl spdy;</div><div><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">      location / {</div><div style="font-family:arial,sans-serif;font-size:13px">

               # this location is reachable using a http:// url when using spdy. If so, we want a redirect to the https:// url. How?</div><div style="font-family:arial,sans-serif;font-size:13px">       }</div><div style="font-family:arial,sans-serif;font-size:13px">

}</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 12:16 AM, Ragnar Rova <span dir="ltr"><<a href="mailto:rr@mima.x.se" target="_blank">rr@mima.x.se</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sorry, my mistake, I was introducing a vulnerability by this.<div><br></div><div>So, without the patch, how do I setup the redirect from http to https urls when a http url was visited over spdy/tls?</div>

<div>
<br></div><div>I have</div><div><br></div><div>server {</div><div><div>       listen <a href="http://1.2.3.4:80" target="_blank">1.2.3.4:80</a>;</div><div><br></div><div>       location ~ ^/(path1|path2)$ {</div><div>                rewrite  ^/(.*)$  <a href="https://mysite.com/$1" target="_blank">https://mysite.com/$1</a>  permanent;</div>


</div><div>                break;</div><div>       }</div><div><br></div><div>       location / {</div><div>                add_header        Alternate-Protocol  443:npn-spdy/2;</div><div>       }</div><div> }</div><div>

<br>
</div><div><div><div>server {</div><div><div>       listen <a href="http://1.2.3.4:443" target="_blank">1.2.3.4:443</a> ssl spdy;</div><div><br></div><div>       location ~ ^/(path1|path2)$ {</div><div>                rewrite  ^/(.*)$  <a href="https://mysite.com/$1" target="_blank">https://mysite.com/$1</a>  permanent;</div>


</div><div>                break;</div><div>       }</div><div> </div><div>      location / {</div><div>               # this location is reachable using a http:// url when using spdy. If so, we want a redirect to the https:// url. How?</div>


<div>       }</div><div>}</div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 29, 2014 at 11:36 PM, Valentin V. Bartenev <span dir="ltr"><<a href="mailto:vbart@nginx.com" target="_blank">vbart@nginx.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Wednesday 29 January 2014 23:06:40 Ragnar Rova wrote:<br>
> # HG changeset patch<br>
> # User Ragnar Rova <<a href="mailto:ragnar.rova@gmail.com" target="_blank">ragnar.rova@gmail.com</a>><br>
> # Date 1391033075 -3600<br>
> #      Wed Jan 29 23:04:35 2014 +0100<br>
> # Node ID 6654eae26c8b2a718e5ad116650faf37f7be7aa9<br>
> # Parent  01e2a5bcdd8f65f4f7bcb23ac35911da08e5945f<br>
> SPDY: set $scheme from scheme request header.<br>
><br>
> $scheme variable is always "https" when using spdy, existing code<br>
> just sets scheme to https based on if we are on a ssl connection.<br>
<br>
</div>Yes, and it is intentionally.<br>
<div><br>
> In spdy, there is a scheme header which should be used.<br>
<br>
</div>There is nothing special about spdy, the scheme also can be passed using<br>
request line in plain http or https, and nginx ignores it too.<br>
<div><br>
> Chrome uses http:// urls when establishing connections to sites using the<br>
> Alternate-Protocol header. If you want some locations to be visible<br>
> to the user as https, you can use $scheme in a http to https<br>
> redirect rule.<br>
<br>
</div>You can use it without this change.  But the patch converts $scheme from<br>
a configuration restricted variable into an untrusted one (which can contain<br>
arbitrary value sent by client).<br>
<br>
  wbr, Valentin V. Bartenev<br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org" target="_blank">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>