[PATCH] SPDY: set $scheme from scheme request header
Ragnar Rova
rr at mima.x.se
Thu Jan 30 13:00:04 UTC 2014
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: https://news.ycombinator.com/item?id=4801641)
But if alternate protocol header has no future then...
Den 30 jan 2014 11:45 skrev "Valentin V. Bartenev" <vbart at nginx.com>:
> 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" <igor at 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 <igor at 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 <rr at 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 <
> vbart at nginx.com>wrote:
> > >>>
> > >>>> On Wednesday 29 January 2014 23:06:40 Ragnar Rova wrote:
> > >>>> > # HG changeset patch
> > >>>> > # User Ragnar Rova <ragnar.rova at 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 at nginx.org
> > >>>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
> > >>>>
> > >>>
> > >>>
> > >> _______________________________________________
> > >> nginx-devel mailing list
> > >> nginx-devel at nginx.org
> > >> http://mailman.nginx.org/mailman/listinfo/nginx-devel
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> nginx-devel mailing list
> > >> nginx-devel at nginx.org
> > >> http://mailman.nginx.org/mailman/listinfo/nginx-devel
> > >>
> > >
> > > _______________________________________________
> > > nginx-devel mailing list
> > > nginx-devel at nginx.org
> > > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> > >
> > >
> > >
> > > _______________________________________________
> > > nginx-devel mailing list
> > > nginx-devel at nginx.org
> > > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> > >
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140130/bbfafdd0/attachment-0001.html>
More information about the nginx-devel
mailing list