Are there any SPDY plans?



  • Richard Still

    Any update on SPDY/HTTP2 support? It seems like the spec nearing completion so it would be good to understand where you guys stand.

  • Austin Spires

    Hey Richard -- Not yet. For something like HTTP/2 support, we'd prefer to do a grand unveil. So I unfortunately don't have any updates.

  • Richard Still

    Hi, Pestering about HTTP2 support again. I appreciate you would like to do a grand unveil but it would be quite handy for those of us looking to use HTTP2 to have a bit of notice so that we can be ready when it arrives! Cloudflare and Akamai are already offering SPDY support so with those guys we can at least plan ahead.

  • Austin Spires

    @richardstillft that's a reasonable request :smile: Shoot us an email at linking to this thread and we'll see what we can do.

  • mootpointer

    So now Apple is supporting HTTP/2, and since there's now an RFC number, can we expect to see HTTP/2 support in the near future?

  • Austin Spires

    @mootpointer We are indeed actively working on HTTP/2 support, but we don't have a publicly releasable go-live date (yet).

  • cherianthomas

    Gentle bug here nearly one year after OP raised the question.

    If it’s of any help, VOX is planning to move all of its properties to a CDN with HTTP/2

  • rlx01

    Just adding my voice to the requests for HTTP/2. And also so I get notified when this thread gets updated.


  • jtangelder

    I'm waiting for this too, and just a reply to keep me updated.

  • keki

    Any updates on this?

  • Rogier Mulhuijzen

    Still a work in progress. We're wanting to do things right.

  • Thomas Genin

    Any updates on this? Thanks

  • ecto

    Also interested in this

  • Thomas Genin

    Can we have an update?

  • tompazourek

    Any updates on this? Other CDNs (cloudflare, akamai, cdn77, etc.) already offer http2 support for a long time...

  • pobrien

    An update on this would be great. H2 is being rolled out by a lot of large websites. Having our CDN able to support H2 would be a pretty big gain for us.

  • Thomas Genin

    The lack of communication on this topic is amazing.

    I am now actively advocating for my company to switch to a new CDN. If it is impossible to have any update regarding this, there is no point to ask for Zopfli client hints, QUIC, etc

  • rlx01

    Hey Thomas, I think the issue here is that there's no HTTP/2 support in Varnish (and likely won't be) so Fastly most likely have to develop this themselves.

    It's not an easy task to get this to be spec compliant, but it's probably something that should have been worked on since SPDY was introduced.

    There's actually a lot to be said for ditching a CDN if your front end servers support HTTP/2 and your CDN doesn't.

  • mattm

    There's actually a lot to be said for ditching a CDN if your front end servers support HTTP/2 and your CDN doesn't.

    Could you expand upon this? I'm new to HTTP/2 and I'm interested to hear why you feel this is the case.

  • Mani Gandham

    [quote="mattm, post:21, topic:193"] Could you expand upon this? I'm new to HTTP/2 and I'm interested to hear why you feel this is the case. [/quote]

    HTTP/2 is a big improvement and greatly reduces latency by combining several requests over the same TCP connection without any blocking by the order of the resources. It also prefers SSL/TLS (via browser support), has header compression and is just faster by being a binary protocol.

    Overall, it can improve loading times for a site even with just a single server. It's still important to use a CDN though to make sure static assets are still closer to an end-user but there are several CDN's that support HTTP/2 now so it's especially glaring that Fastly is still stuck on HTTP/1, regardless of their foundation built on Varnish.

  • Austin Spires

    Hey everyone. As @Thomas_Genin pointed out, we’ve been delayed on delivering HTTP/2 beyond what we alluded to previously, and we’ve been slow to update here. I’m sorry. This level of radio silence isn’t acceptable to us, and you all deserve to know the full story.

    To start, we’ve been researching or working on HTTP/2 since around the start of this thread. The process began with investigating existing open source options, as @rlx01 and others have mentioned. However in the feasibility research, we did uncover several problems that put up major blockers in that process. To start, many of the libraries in existence aren’t designed with Fastly’s request and network load in mind; this was not something that surprised us. Existing OSS options are built for more normal uses, and we fully anticipated that off-the-shelf options would need to be reworked. However, we ran into another problem that caused a significant reassessment of our protocol approaches overall. HTTP2, in it’s design process, was built and tested under controlled environments. For a research-driven protocol, this is the right thing. In this approach, the protocol benefits from the most long-term focused scoping and specification work possible, ensuring a greater lifetime of adoption and stability. This does place additional complications around implementation (which I’ll address later), but that’s a normal process. However, when we began testing HTTP/2 in real world network simulations, we uncovered several conditions where HTTP/2 performance is comparable-to or below HTTP/1. The tests themselves don’t fit our standards for publishable research (full reproducibility under the scientific method), so we’ve been hesitant to share details until we have data to our standards. But, these findings were enough to cause us to rethink and replan our implementation from the ground up.

    The crux of the matter is: if we’ve seen, even in our own early testing, that there are fleeting network conditions where HTTP/2 is inferior to HTTP/1.1, and if we have a burden as a service provider to always provide the fastest network connection to our customer’s end users no matter what, we need to develop an intelligent way to detect network problems and select the best protocol options in real time for any end user automatically. Our number one priority, by an order of magnitude, is network stability. We have to build with this in mind. When we roll out IPv6, when we build HTTP/2 support, when we research QUIC support (which we are, of course), or when we add more features to Varnish, we have to architect and build with stability as a high focus.

    So, with these situations in mind, we’re still building HTTP/2 support in a way that’s robust enough to meet our standards, and in a way that can intelligently handle the odd network edge cases that don’t benefit from HTTP/2’s features and functionality. Unfortunately, we are still working, and we don’t have an active beta. We’ve also learned the hard way in threads like this that stating a release date prematurely is a recipe for bad emotions if a project is delayed, so we’re not going to post a timeline until it’s nearly done.

    The discerning reader will point out that this thread has been around for a long time, much more so than a well-oiled engineering organization would need to work through the above timeline. As one might reasonably conclude, there were some considerable management and coordination challenges with a large scale project of this undertaking as we grew from a small startup to full-scale growing business. If you’ve been at a company that’s grown from 10 to 50 to 100 to 300+ over the span of a few years, you know what I’m alluding to: processes slow down, new employees don’t have the same institutional knowledge as veterans, and the assumptions around building and shipping code no longer hold. As a result, output drops. I mention this not to make excuses, but to to be transparent about how we got to this point in our lifecycle.

    That said, over the past 4-5 months, we’ve been putting in substantial changes to our organizations for engineering happiness and shipping velocity. To not drag out an already long piece with gory details, but we have dedicated teams owning core products in the long term and we have widely adopted (but still flexible) development practices. Across the board, with our application team, our systems teams, and even our teams researching protocols, we’re at a point of velocity that we haven’t seen since the early scrappy startup days, and this should directly impact our ability to get out HTTP/2.

    All in all, we’re sorry that things have taken this long, and we’re sorry that we’ve been so slow to fully update our message on this. As Fastly customers, you deserve better. All in all, I hope this paints an honest picture of what happened on the technical and human side to cause us to get to this state. We’ve made changes that should prevent this from happening again in the future, and I hope we can regain your trust over time.

  • Dean Taylor

    [quote="ManiGandham, post:22, topic:193"] It also prefers SSL/TLS (via browser support) [/quote]

    Really HTTP 2 / SPDY requires SSL/TLS, this taken from the HTTP2 FAQ:

    However, some implementations have stated that they will only support HTTP/2 when it is used over an encrypted connection, and currently no browser supports HTTP/2 unencrypted.

  • Mani Gandham

    Really HTTP 2 / SPDY requires SSL/TLS, this taken from the HTTP2 FAQ:

    Yes, this is what I said but perhaps I should've phrased it better. The protocol doesn't require it but browsers do so effectively TLS is necessary.

  • Mani Gandham

    I got a notification about a post on this thread from Fastly member @aspires but it seems they deleted it immediately, which is strange...

  • Austin Spires

    @ManiGandham we're converting the update to a blog post for a wider reach. As much as I'd like it, not everyone is a power user to the point where they visit the forum like ya'll do.

  • mattm

    @aspires I imagine this is outside of your control but it doesn't look great to finally post something on a thread that hasn't been updated by Fastly in months and then pull it down less than 24 hours later. For all of us who have notifications enabled in the thread, we already all have the full text in our email inbox. Why not just leave it up for this smaller audience?

  • Community

    An updated blog post addressing our HTTP/2 timeline has been posted on the blog - you can read more here:

  • Austin Spires

    Here it is (in limited availability). Sign on up by emailing :two: :clock2:

Please sign in to leave a comment.