SPDY 4

[nutinshell]

Any plan to support SPDY 4?

[rraptorr]

Was SPDY 4 even released? Are there any specifications available?
As far as I know there it no SPDY 4 currently, it is a provisional version for future SPDY releases. Google makes some experiments with Chrome, but it is nothing that can be implemented currently.

[tatsuhiro-t]

I heard that SPDY 4 is basically HTTP/2.0 + some experimental features Google wants to try out.
But currently gfs says spdy/4a4, but no one knows what that protocol does.

BTW if you are interested in HTTP/2.0, take a look at nghttpx proxy in https://github.com/tatsuhiro-t/nghttp2 project. Basically, the project itself is a fork from spdylay and nghttpx is a fork of shrpx.
nghttpx supports SPDY with the help of libspdylay.

[ghost]

Shrpx is outperforming everything I'm comparing to. It's amazing!

I've found two missing features that (if added) would make shrpx/nghttp2 a complete replacement for HAProxy in my environment.

1. If a client attempts to use the HTTP protocol automatically 301 redirect to the HTTPS protocol.

I'm upstreaming to NGINX via SPDY; however, since the upstream NGINX always sees an incoming SSL request it will not know the end user on non SSL client and thus I can't tell if I need to 301 redirect the client to SSL (or is there a way to pass a header from the client through shrpx/nghttp2 to NGINX if that's a solution?).

If the job of 301 redirect was pushed forward to shrpx/nghttp2 that would solve the issue and remove one small task from NGINX.

2. If we could specify multiple back ends and shrpx/nghttp2 distribute to upstreams via a simple round-robin algorithm and that would make for a simple load balancer. In theory taking metrics from upstream SPDY connections might be a great way to determine what is going upstream for intelligent load balancing.

If both of these features were in nghttp2 that would be sweet!

[tatsuhiro-t]

1. If a client attempts to use the HTTP protocol automatically 301 redirect to the HTTPS protocol.

From your post, I understand that shprx speaks SPDY to backend nginx.
In this case, if the client talking to shrpx uses non SSL, shrpx sends ":scheme: http" header field to nginx. If client uses SSL, shrpx sends ":scheme: https" instead.

If shrpx speaks to nginx in plain HTTP/1, shrpx sends X-Forwarded-Proto header field, with "http" or "https" depending on the protocol client uses.

Since ":scheme" header field is SPDY specific header field and it may not be available to user callback in nginx configuration. I'm OK to add X-Forwarded-Proto header field for the SPDY backend as well.

2. If we could specify multiple back ends and shrpx/nghttp2 distribute to upstreams via

This will involve fair amount of code change since current codebase only considers one backend.
Could you raise the new issue for this?

[tatsuhiro-t]

0da1835 adds X-Forwarded-Proto to SPDY backend request.