<p dir="ltr">It hurts performance a tiny bit with a TLS handshake and 301 with extra request, so for non spdy clients it would slow things down in terms of initial page speed to make the entire site https . Also making the entire site 301 to https might be bad for SEO (just guessing here, i might be wrong: <a href="https://news.ycombinator.com/item?id=4801641">https://news.ycombinator.com/item?id=4801641</a>)</p>
<p dir="ltr">But if alternate protocol header has no future then...</p>
<div class="gmail_quote">Den 30 jan 2014 11:45 skrev "Valentin V. Bartenev" <<a href="mailto:vbart@nginx.com">vbart@nginx.com</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thursday 30 January 2014 10:05:04 Ragnar Rova wrote:<br>
> Sorry for the confusion regarding scheme value and actual connection method<br>
> used. In my above example chrome is using a SSL connection to port 443 to<br>
> fetch /foo/a.html, (verified using tcpdump), but the location field shows<br>
> http://.<br>
<br>
This is indeed very strange. But if you don't want user to see "http"<br>
in his location bar, why do you use Alternate-Protocol instead of just<br>
redirecting them to https?<br>
<br>
This Alternate-Protocol thing is not well defined and was removed from<br>
SPDY specification in draft 3 or above.<br>
<br>
wbr, Valentin V. Bartenev<br>
<br>
<br>
> Den 30 jan 2014 09:57 skrev "Igor Sysoev" <<a href="mailto:igor@sysoev.ru">igor@sysoev.ru</a>>:<br>
><br>
> > On Jan 30, 2014, at 12:07 , Ragnar Rova wrote:<br>
> ><br>
> > Maybe its a Chrome bug, but I have seen chrome connecting over ssl/spdy<br>
> > and setting the scheme: header to "http"<br>
> ><br>
> ><br>
> > This is not bug, you can start Chrome with "--spdy=no-ssl" or probably<br>
> > "--use-spdy=no-ssl" command line option and<br>
> > then Chrome will request spdy over plain socket but as far as I know this<br>
> > is experimental feature.<br>
> ><br>
> > --<br>
> > Igor Sysoev<br>
> > <a href="http://nginx.com" target="_blank">http://nginx.com</a><br>
> ><br>
> > From the users point of view it is not visible that a ssl connection was<br>
> > used (no padlock icon etc), so I wanted a redirect to the https:// url<br>
> > (mainly to show to the user that it is https)<br>
> ><br>
> > Using this to reproduce:<br>
> ><br>
> > server {<br>
> > listen <a href="http://1.2.3.4:80" target="_blank">1.2.3.4:80</a> <<a href="http://1.2.3.4/" target="_blank">http://1.2.3.4/</a>>;<br>
> ><br>
> > location /foo {<br>
> > return 301 <a href="https://mysite.com" target="_blank">https://mysite.com</a>$request_uri;<br>
> > }<br>
> ><br>
> > location / {<br>
> > add_header Alternate-Protocol 443:npn-spdy/2;<br>
> ><br>
> > ...<br>
> ><br>
> > }<br>
> > }<br>
> ><br>
> > server {<br>
> > listen <a href="http://1.2.3.4:443" target="_blank">1.2.3.4:443</a> ssl spdy;<br>
> ><br>
> > location /foo {<br>
> > alias "/tmp/foo";<br>
> > }<br>
> > }<br>
> ><br>
> > 1. Empty browser cache<br>
> > 2. Visit <a href="http://mysite.com" target="_blank">http://mysite.com</a> so that chrome learns of the<br>
> > alternate-protocol and will make next connection using spdy<br>
> > 3. Now go to <a href="http://mysite.com/foo/a.html" target="_blank">http://mysite.com/foo/a.html</a><br>
> ><br>
> > Expected https:// in the location field. (Of course, the connection is<br>
> > over ssl/spdy port 443 when fetching /foo/a.html). Tested using Chrome<br>
> > 32.0.1700.102<br>
> ><br>
> > I was testing also using spdylay (<a href="https://github.com/tatsuhiro-t/spdylay" target="_blank">https://github.com/tatsuhiro-t/spdylay</a>)<br>
> > where I can request with "http" scheme by using a url on the form<br>
> > <a href="http://mysite.com:443/foo/a.html" target="_blank">http://mysite.com:443/foo/a.html</a>.<br>
> ><br>
> ><br>
> ><br>
> > On Thu, Jan 30, 2014 at 7:48 AM, Igor Sysoev <<a href="mailto:igor@sysoev.ru">igor@sysoev.ru</a>> wrote:<br>
> ><br>
> >> On Jan 30, 2014, at 3:18 , Ragnar Rova wrote:<br>
> >><br>
> >> Was a bit too quick with example, meant the 443 server does not have such<br>
> >> a rewrite, that would mean a loop.<br>
> >><br>
> >> server {<br>
> >> listen <a href="http://1.2.3.4:443" target="_blank">1.2.3.4:443</a> ssl spdy;<br>
> >><br>
> >> location / {<br>
> >> # this location is reachable using a http:// url when<br>
> >> using spdy. If so, we want a redirect to the https:// url. How?<br>
> >> }<br>
> >> }<br>
> >><br>
> >><br>
> >> server {<br>
> >> listen <a href="http://1.2.3.4:443" target="_blank">1.2.3.4:443</a> ssl spdy;<br>
> >><br>
> >> location / {<br>
> >> error_page 497 =301 <a href="https://mysite.com" target="_blank">https://mysite.com</a>$request_uri;<br>
> >> ...<br>
> >> }<br>
> >><br>
> >> <a href="http://nginx.org/en/docs/http/ngx_http_ssl_module.html#errors" target="_blank">http://nginx.org/en/docs/http/ngx_http_ssl_module.html#errors</a><br>
> >> <a href="http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page" target="_blank">http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page</a><br>
> >><br>
> >> As to "http://" URLs over SPDY, this is impossible now since no browser<br>
> >> support this.<br>
> >><br>
> >><br>
> >> --<br>
> >> Igor Sysoev<br>
> >> <a href="http://nginx.com" target="_blank">http://nginx.com</a><br>
> >><br>
> >><br>
> >> On Thu, Jan 30, 2014 at 12:16 AM, Ragnar Rova <<a href="mailto:rr@mima.x.se">rr@mima.x.se</a>> wrote:<br>
> >><br>
> >>> Sorry, my mistake, I was introducing a vulnerability by this.<br>
> >>><br>
> >>> So, without the patch, how do I setup the redirect from http to https<br>
> >>> urls when a http url was visited over spdy/tls?<br>
> >>><br>
> >>> I have<br>
> >>><br>
> >>> server {<br>
> >>> listen <a href="http://1.2.3.4:80" target="_blank">1.2.3.4:80</a> <<a href="http://1.2.3.4/" target="_blank">http://1.2.3.4/</a>>;<br>
> >>><br>
> >>> location ~ ^/(path1|path2)$ {<br>
> >>> rewrite ^/(.*)$ <a href="https://mysite.com/$1" target="_blank">https://mysite.com/$1</a> permanent;<br>
> >>> break;<br>
> >>> }<br>
> >>><br>
> >>> location / {<br>
> >>> add_header Alternate-Protocol 443:npn-spdy/2;<br>
> >>> }<br>
> >>> }<br>
> >>><br>
> >>> server {<br>
> >>> listen <a href="http://1.2.3.4:443" target="_blank">1.2.3.4:443</a> ssl spdy;<br>
> >>><br>
> >>> location ~ ^/(path1|path2)$ {<br>
> >>> rewrite ^/(.*)$ <a href="https://mysite.com/$1" target="_blank">https://mysite.com/$1</a> permanent;<br>
> >>> break;<br>
> >>> }<br>
> >>><br>
> >>> location / {<br>
> >>> # this location is reachable using a http:// url when<br>
> >>> using spdy. If so, we want a redirect to the https:// url. How?<br>
> >>> }<br>
> >>> }<br>
> >>><br>
> >>><br>
> >>> On Wed, Jan 29, 2014 at 11:36 PM, Valentin V. Bartenev <<a href="mailto:vbart@nginx.com">vbart@nginx.com</a>>wrote:<br>
> >>><br>
> >>>> 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">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>
> >>>> Yes, and it is intentionally.<br>
> >>>><br>
> >>>> > In spdy, there is a scheme header which should be used.<br>
> >>>><br>
> >>>> 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>
> >>>><br>
> >>>> > Chrome uses http:// urls when establishing connections to sites<br>
> >>>> 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>
> >>>> You can use it without this change. But the patch converts $scheme from<br>
> >>>> a configuration restricted variable into an untrusted one (which can<br>
> >>>> 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">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>
> >>>><br>
> >>><br>
> >>><br>
> >> _______________________________________________<br>
> >> nginx-devel mailing list<br>
> >> <a href="mailto:nginx-devel@nginx.org">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>
> >><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> nginx-devel mailing list<br>
> >> <a href="mailto:nginx-devel@nginx.org">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>
> >><br>
> ><br>
> > _______________________________________________<br>
> > nginx-devel mailing list<br>
> > <a href="mailto:nginx-devel@nginx.org">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>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > nginx-devel mailing list<br>
> > <a href="mailto:nginx-devel@nginx.org">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>
> ><br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">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>