On Thursday 30 January 2014 10:05:04 Ragnar Rova wrote: > Sorry for the confusion regarding scheme value and actual connection method > used. In my above example chrome is using a SSL connection to port 443 to > fetch /foo/a.html, (verified using tcpdump), but the location field shows > http://.
This is indeed very strange. But if you don't want user to see "http" in his location bar, why do you use Alternate-Protocol instead of just redirecting them to https? This Alternate-Protocol thing is not well defined and was removed from SPDY specification in draft 3 or above. wbr, Valentin V. Bartenev > Den 30 jan 2014 09:57 skrev "Igor Sysoev" <i...@sysoev.ru>: > > > On Jan 30, 2014, at 12:07 , Ragnar Rova wrote: > > > > Maybe its a Chrome bug, but I have seen chrome connecting over ssl/spdy > > and setting the scheme: header to "http" > > > > > > This is not bug, you can start Chrome with "--spdy=no-ssl" or probably > > "--use-spdy=no-ssl" command line option and > > then Chrome will request spdy over plain socket but as far as I know this > > is experimental feature. > > > > -- > > Igor Sysoev > > http://nginx.com > > > > From the users point of view it is not visible that a ssl connection was > > used (no padlock icon etc), so I wanted a redirect to the https:// url > > (mainly to show to the user that it is https) > > > > Using this to reproduce: > > > > server { > > listen 1.2.3.4:80 <http://1.2.3.4/>; > > > > location /foo { > > return 301 https://mysite.com$request_uri; > > } > > > > location / { > > add_header Alternate-Protocol 443:npn-spdy/2; > > > > ... > > > > } > > } > > > > server { > > listen 1.2.3.4:443 ssl spdy; > > > > location /foo { > > alias "/tmp/foo"; > > } > > } > > > > 1. Empty browser cache > > 2. Visit http://mysite.com so that chrome learns of the > > alternate-protocol and will make next connection using spdy > > 3. Now go to http://mysite.com/foo/a.html > > > > Expected https:// in the location field. (Of course, the connection is > > over ssl/spdy port 443 when fetching /foo/a.html). Tested using Chrome > > 32.0.1700.102 > > > > I was testing also using spdylay (https://github.com/tatsuhiro-t/spdylay) > > where I can request with "http" scheme by using a url on the form > > http://mysite.com:443/foo/a.html. > > > > > > > > On Thu, Jan 30, 2014 at 7:48 AM, Igor Sysoev <i...@sysoev.ru> wrote: > > > >> On Jan 30, 2014, at 3:18 , Ragnar Rova wrote: > >> > >> Was a bit too quick with example, meant the 443 server does not have such > >> a rewrite, that would mean a loop. > >> > >> server { > >> listen 1.2.3.4:443 ssl spdy; > >> > >> location / { > >> # this location is reachable using a http:// url when > >> using spdy. If so, we want a redirect to the https:// url. How? > >> } > >> } > >> > >> > >> server { > >> listen 1.2.3.4:443 ssl spdy; > >> > >> location / { > >> error_page 497 =301 https://mysite.com$request_uri; > >> ... > >> } > >> > >> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#errors > >> http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page > >> > >> As to "http://"; URLs over SPDY, this is impossible now since no browser > >> support this. > >> > >> > >> -- > >> Igor Sysoev > >> http://nginx.com > >> > >> > >> On Thu, Jan 30, 2014 at 12:16 AM, Ragnar Rova <r...@mima.x.se> wrote: > >> > >>> Sorry, my mistake, I was introducing a vulnerability by this. > >>> > >>> So, without the patch, how do I setup the redirect from http to https > >>> urls when a http url was visited over spdy/tls? > >>> > >>> I have > >>> > >>> server { > >>> listen 1.2.3.4:80 <http://1.2.3.4/>; > >>> > >>> location ~ ^/(path1|path2)$ { > >>> rewrite ^/(.*)$ https://mysite.com/$1 permanent; > >>> break; > >>> } > >>> > >>> location / { > >>> add_header Alternate-Protocol 443:npn-spdy/2; > >>> } > >>> } > >>> > >>> server { > >>> listen 1.2.3.4:443 ssl spdy; > >>> > >>> location ~ ^/(path1|path2)$ { > >>> rewrite ^/(.*)$ https://mysite.com/$1 permanent; > >>> break; > >>> } > >>> > >>> location / { > >>> # this location is reachable using a http:// url when > >>> using spdy. If so, we want a redirect to the https:// url. How? > >>> } > >>> } > >>> > >>> > >>> On Wed, Jan 29, 2014 at 11:36 PM, Valentin V. Bartenev > >>> <vb...@nginx.com>wrote: > >>> > >>>> On Wednesday 29 January 2014 23:06:40 Ragnar Rova wrote: > >>>> > # HG changeset patch > >>>> > # User Ragnar Rova <ragnar.r...@gmail.com> > >>>> > # Date 1391033075 -3600 > >>>> > # Wed Jan 29 23:04:35 2014 +0100 > >>>> > # Node ID 6654eae26c8b2a718e5ad116650faf37f7be7aa9 > >>>> > # Parent 01e2a5bcdd8f65f4f7bcb23ac35911da08e5945f > >>>> > SPDY: set $scheme from scheme request header. > >>>> > > >>>> > $scheme variable is always "https" when using spdy, existing code > >>>> > just sets scheme to https based on if we are on a ssl connection. > >>>> > >>>> Yes, and it is intentionally. > >>>> > >>>> > In spdy, there is a scheme header which should be used. > >>>> > >>>> There is nothing special about spdy, the scheme also can be passed using > >>>> request line in plain http or https, and nginx ignores it too. > >>>> > >>>> > Chrome uses http:// urls when establishing connections to sites > >>>> using the > >>>> > Alternate-Protocol header. If you want some locations to be visible > >>>> > to the user as https, you can use $scheme in a http to https > >>>> > redirect rule. > >>>> > >>>> You can use it without this change. But the patch converts $scheme from > >>>> a configuration restricted variable into an untrusted one (which can > >>>> contain > >>>> arbitrary value sent by client). > >>>> > >>>> wbr, Valentin V. Bartenev > >>>> > >>>> _______________________________________________ > >>>> nginx-devel mailing list > >>>> nginx-devel@nginx.org > >>>> http://mailman.nginx.org/mailman/listinfo/nginx-devel > >>>> > >>> > >>> > >> _______________________________________________ > >> nginx-devel mailing list > >> nginx-devel@nginx.org > >> http://mailman.nginx.org/mailman/listinfo/nginx-devel > >> > >> > >> > >> _______________________________________________ > >> nginx-devel mailing list > >> nginx-devel@nginx.org > >> http://mailman.nginx.org/mailman/listinfo/nginx-devel > >> > > > > _______________________________________________ > > nginx-devel mailing list > > nginx-devel@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > > > > > > > _______________________________________________ > > nginx-devel mailing list > > nginx-devel@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
