ERR_SPDY_PROTOCOL_ERROR when enabling SPDY
Hi ! I use BIG-IP 11.6.0 and try to enable SPDY. I have a VS with an Access Policy that uses an 'External Logon Page' action. My config: ifile with a custom login page VS with: No Client SSL profile An AP that starts with an 'External Logon Page' action with a Server URI '/login' A pool select irule used to direct traffic to the login ifile : switch -regexp -- [string tolower [HTTP::path]] { "^/login(/|$)" { HTTP::respond 200 content [ifile get login-form] ... } ... (pool selects for actual services) ... } In front of this VS I have another VS. It has a Client SSL profile Without SPDY When I don't have SPDY enabled on my front VS everything works: /myservice 302 -> /my.policy 200 OK (APM will initiate a POST to the external logon page, /login) /login 200 OK. (/login is an iFile) user enters credentials (/login POST's these to /my.policy) -> /my.policy 302 -> /myservice (and I'm logged in) With SPDY When I enable SPDY on the front VS, things break: /myservice 302 -> /my.policy 200 OK (APM will initiate a POST to the external logon page, /login) /login ( This request is made, but bad/no response is received by the client) Chrome shows 'not available, ERR_SPDY_PROTOCOL_ERROR'. dev tool shows 'CAUTION: Provisional headers are shown' in place of request headers. No reponse headers are shown FF shows 'Secure Connection Failed' IE works In the ltm log I can see: the AP in the inner VS has started the /login ifile has been served the outer VS has fired a HTTP_RESPONSE event There are no log entries in apm or ltm other than those i make myself if I go directly to the custom login page (i.e. https://mysite.no/login) I get the same error. If I repeat the request for the custom login page, it works (!) I make no other change than enabling SPDY. If I disable SPDY again everything works normally. Any tips on how to figure out this issue? I find nothing in the BIG-IP logs, error messages from the browsers are very generic, and since SPDY only works over HTTPS listening in on the traffic is difficult.SPDY/HTTP2 Profile Impact on Variable Use
When using SPDY/HTTP2 profile, TCL variables set before the HTTP_REQUEST event are not carried over to further events. This is by design as the current iRule/TCL implementation is not capable of handling multiple concurrent events, which may be they case with SPDY/HTTP2 multiplexing. This is easily reproducible with this simple iRule: when CLIENT_ACCEPTED { set default_pool [LB::server pool] } when HTTP_REQUEST { log local0. "HTTP_REQUEST EVENT Client [IP::client_addr]:[TCP::client_port] - $default_pool -" # - can't read "default_pool": no such variable while executing "log local0. "HTTP_REQUEST EVENT -- $default_pool --" } Storing values in a table works perfectly well and can be used to work around the issue as shown in the iRule below. when CLIENT_ACCEPTED { table set [IP::client_addr]:[TCP::client_port] [LB::server pool] } when HTTP_REQUEST { set default_pool [table lookup [IP::client_addr]:[TCP::client_port]] log local0. "POOL: |$default_pool|" } This information is also available in the wiki on the HTTP2 namespace command list page.AAM Dynamic Policy Updates And Removal of SPDY in BIG-IP v13
February 22nd marked the downloadable release of F5 BIG-IP v13. With any major release, our user community wants to know what changes and features will present themselves post upgrade. For BIG-IP Application Acceleration Manager (AAM) users, there are two changes users can expect. Under-the-hood, users will enjoy improved performance in Bandwidth Controller updates for Dynamic Policies. For those who deployed SPDY services, keep reading. Dynamic Policy Updates Maybe you implemented dynamic bandwidth policies and maaaayyybeeee you saw policies not always metering "fairly" causing throttling prior to peak utilization. We saw it too. The algorithms behind the fairness policies within Bandwidth Controller and their surrounding policy management are updated to properly maximize your available bandwidth. BIG-IP v13 modifies existing static and common token bucket algorithms. For you this means: Better tracking of slow flows Better utilize assigned max rates in all conditions Better control of max rate and token distributions across TMM instances and blades These updates require no user intervention to implement. If you have existing policies already in use, you should see performance improvements immediately. There are two mechanisms for assigning policy-based flow rates in AAM, Policy Enforcement Manager and Access Policy Manager (and iRules if you're splitting hairs) but actual changes for these improvements reside within Bandwidth Controller. Say Goodby to SPDY Google announced removal of SPDY support in favor of HTTP/2 Februrary 2015. SPDY (and NPN) support were removed from Chrome in February 2016. All other major browsers followed suit or are planning to drop support shortly. F5 introduced HTTP/2 support in 11.6 and with version 13 we complete SPDY's removal as a functioning service. SPDY service profiles in v12 SPDY profiles create is removed in v13 SPDY profiles create is removed in v13 If for some reason you had a SPDY-only virtual server/application, kudo's for being that one person and let's start making plans to migrate your SPDY gateway/services to HTTP/2 before your upgrade. SPDY functionality exists in LTM and AAM and GUI removal applies to both. We don't want you to be surprised. SPDY removal and Bandwidth Controller fairness algorithm updates are the two changes you'll see affect AAM (and other modules) in BIG-IP v13. One requires no intervention and will provide performance increases, the other is a deprecated web standard who should already have both feet out your infrastructure door. Let us know your experiences with BIG-IP v13 keep on IT'ing
What are you waiting for?
The future of HTTP is here, or almost here. It has been 5 years since SPDY was first introduced as a better way to deliver web sites. A lot has happened since then. Chrome, Firefox, Opera and some IE installations support SPDY. SPDY evolved from v2 to v3 to v3.1. Sites like Google, Facebook, Twitter, and Wordpress to name just a few are available via SPDY. F5 announced availability of a SPDY Gateway. The IETF HTTP working group announced SPDY is the starting point for HTTP/2. And most recently - Apple has announced that Safari 8, due out this fall, will support SPDY! This means that all major browsers will support SPDY by the end of the year. By the end of the year all major browsers will support SPDY, and the IETF is scheduled to have the HTTP/2 draft finalized. This week the IETF working group published the latest draft of the HTTP/2 spec. The hope is that this will be the version that becomes the proposed RFC. The Internet Explorer team posted a blog at the end of May indicating that they have HTTP/2 in development for a future version of IE, there is no commitment whether this will be in IE 12 or another version but they are preparing for the shift. We at F5, have been following the evolution of the spec and developing prototypes based on the various interoperability drafts to make sure we are ready as soon as possible to implement an HTTP/2 gateway. So what are you waiting for, why are you not using SPDY on your site? Using SPDY today allows you to see how HTTP/2 may potentially impact your applications and infrastructure. HTTP/2 is not a new protocol, there are no changes to the HTTP semantics and it does not obsolete the existing HTTP/1.1 message syntax. If it’s not a new protocol and it doesn’t obsolete HTTP/1.1 what is HTTP/2 exactly? Per the draft’s abstract: This specification describes an optimized expression of the syntax of the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent messages on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. HTTP/2 allows communication to occur with less data transmitted over the network and with the ability to send multiple requests and responses across a single connection, out of order and interleaved – oh yeah and all over SSL. Let’s look at these in a little more detail. Sending less data has always been a good thing but just how much improvement can be achieved by compressing headers. It turns out quite a bit. Headers have a lot of repetitive information in them: the cookies, encoding types, cache settings to name just a few. With all this repetitive information compression can really help. Looking at the amount of downloaded data for a web page delivered over HTTP and over SPDY we can see just how much savings can be achieved. Below is a sample of 10 objects delivered over HTTP and SPDY, the byte savings result in a total savings of 1762 bytes. That doesn’t sound like much but we’re only talking about 10 objects. The average home page now has close to 100 objects on it, and I’m sure the total number of hits to your website is well over that number. If your website gets 1 million hits a day then extrapolating this out the savings become 168 MB, if the hits are closer to 10 million the savings nears 1.7 GB. Over the course of a month or a year these savings will start to add up. HTTP SPDY Byte Savings https://.../SitePages/Home.aspx 29179 29149 30 https://.../_layouts/1033/core.js 84457 84411 46 https://.../_layouts/sp.js 71834 71751 83 https://.../_layouts/sp.ribbon.js 57999 57827 172 https://.../_layouts/1033/init.js 42055 41864 191 https://.../_layouts/images/fgimg.png 20478 20250 228 https://.../_layouts/images/homepageSamplePhoto.jpg 16935 16704 231 https://.../ScriptResource.axd 27854 27617 237 https://.../_layouts/images/favicon.ico 5794 5525 269 https://.../_layouts/blank.js 496 221 275 SPDY performed header compression via deflate, this was discovered to be vulnerable to CRIME attacks, as a result HTTP/2 uses HPACK header compression, an HTTP header specific compression scheme which is not vulnerable to CRIME. The next element to examine is the ability to send multiple requests and response across a single connection, out of order and interleaved. We all know that latency can have a big impact on page load times and the end user experience. This is why HTTP 1.1 allowed for keep-alives, eliminating the need to perform a three way handshake for each and every request. After keep alives came, domain sharding and browsers eventually changed the default behavior to allow more than 2 concurrent TCP connections. The downside of multiple TCP connections is having to conduct the three way handshake multiple times, wouldn’t things be easier if all requests could just be sent over a single TCP connection. This is what HTTP/2 provides, and not only that the responses can be returned in a different order in which they were reqeusted. Now onto the SSL component. HTTP/2 requires strong crypto –128 bit EC or 2048 bit RSA. This requirement will be enforced by browsers and cannot be disabled. With the ever growing number of attacks having SSL everywhere is a good thing but there are performance and reporting ramifications to encrypting all data. Organizations that deploy solutions to monitor, classify and analyze Internet traffic may no longer be able to do so. All the changes coming in HTTP/2 have the potential to impact how an application is rendered and how infrastructure components will react. What are the consequences of having all requests and responses transmitted over SSL, can the network support 50 concurrent requests for objects, does the page render properly for the end user if objects are received out of order? On the positive you could end up with improved page load times and a reduction in the amount of data transferred, stop waiting and start enabling the future of the web today.
Goodbye SPDY, Hello HTTP/2
The Chrome team at Google recently announced that they will be removing SPDY support from Chrome in early 2016. SPDY is an application layer protocol designed to improve the way that data is sent from web servers to clients. Depending on who you read, performance benefits ranged from a 2X speed increase down to negligible. Now, since here in March 2015 only 3.6% of websites were running SPDY, maybe the end of SPDY isn’t such big news, especially since SPDY is being replaced by HTTP/2. The HTTP/2 protocol is on the way to standardization, has pretty much all of the benefits of SPDY and will undoubtedly become the standard for web traffic moving forward. All of this is great, unless you are the one who is tasked with reconfiguring or re-implementing your server estate to switch form SPDY to HTTP/2. Fortunately, for those F5 customers who implemented SPDY using the SPDY gateway feature in BIG-IP LTM, switching to HTTP/2 is easy. TMOS 11.6 ships with HTTP/2 support – we’ve cautiously labeled this as ‘for testing’ – after all the protocol has only just been finalized. All you need to do is configure an HTTP/2 profile and apply it to your Virtual Server, and (where clients are HTTP/2 capable) you are serving HTTP/2 – it’s about 10 minutes work. This also give you a way to offer HTTP/2 support without changing your HTTP/1.x backend, which is handy because, based on the evidence of IE6, old web browsers can take a decade or more to die. In fact, maybe I should get my patent lodged for software to connect aging browsers to the next generation of web infrastructure?
11.6.0 SPDY Connection from iOS 8
Sorry to make this so generic, but has anybody seen an iOS 8 device successfully connect to a SPDY enabled virtual server on 11.6.0? I've tried applying /Common/spdy under both HF1 and HF3, and iOS devices stop being able to connect. Wireshark shows rapid connection attempts until the user cancels. Safari on Yosemite also seems unhappy, but every other browser functions correctly and the statistics show plenty of SPDY requests happening. Thanks for any sanity check you can offer.F5 Friday: Should you stay with HTTP/1 or move to HTTP/2 ?
Application experience aficionados take note: you have choices now. No longer are you constrained to just HTTP/1 with a side option of WebSockets or SPDY. HTTP/2 is also an option, one that like its SPDY predecessor brings with it several enticing benefits but is not without obstacles. In fact, it is those obstacles that may hold back adoption according to IDG research, "Making the Journey to HTTP/2". In the research, respondents indicated several potential barriers to adoption including backward compatibility with HTTP/1 and the "low availability" of HTTP/2 services. In what's sure to noticed as a circular dependency, the "low availability" is likely due to the "lack of backward compatibility" barrier. Conversely, the lack of backward compatibility with HTTP/1 is likely to prevent the deployment of HTTP/2 services and cause low availability of HTTP/2 services. Which in turn, well, you get the picture. This is not a phantom barrier. The web was built on HTTP/1 and incompatibility is harder to justify today than it was when we routinely browsed the web and were shut out of cool apps because we were using the "wrong" browser. The level of integration between apps and reliance on many other APIs for functionality pose a difficult problem for would-be adopters of HTTP/2 looking for the improved performance and efficacy of resource utilization it brings. But it doesn't have to. You can have your cake and eat it too, as the saying goes. HTTP Gateways What you want is some thing that sits in between all those users and your apps and speaks their language (protocol) whether it's version 1 or version 2. You want an intermediary that's smart enough to translate SPDY or HTTP/2 to HTTP/1 so you don't have to change your applications to gain the performance and security benefits without investing hundreds of hours in upgrading web infrastructure. What you want is an HTTP Gateway. At this point in the post, you will be unsurprised to learn that F5 provides just such a thing. Try to act surprised, though, it'll make my day. One of the benefits of growing up from a load balancing to an application delivery platform is that you have to be fluent in the languages (protocols) of applications. One of those languages is HTTP, and so it's no surprise that at the heart of F5 services is the ability to support all the various flavors of HTTP available today: HTTP/1, SPDY, HTTP/2 and HTTP/S (whether over TLS or SSL). But more than just speaking the right language is the ability to proxy for the application with the user. Which means that F5 services (like SDAS) sit in between users and apps and can translate across flavors of HTTP. Is your mobile app speaking HTTP/2 or SPDY but your app infrastructure only knows HTTP/1? No problem. F5 can make that connection happen. That's because we're a full proxy, with absolute control over a dual-communication stack that lets us do one thing on the client side while doing another on the server side. We can secure the outside and speak plain-text on the inside. We can transition security protocols, web protocols, and network protocols (think IPv4 - IPv6). That means you can get those performance and resource-utilization benefits without ripping and replacing your entire web application infrastructure. You don't have to reject users because they're not using the right browser protocol and you don't have to worry about losing visibility because of an SSL/TLS requirement. You can learn more about F5's HTTP/2 and SDPY Gateway capabilities by checking out these blogs: What are you waiting for? F5 Synthesis: Your gateway to the future (of HTTP) Velocity 2014 HTTP 2.0 Gateway (feat Parzych) F5 Synthesis Reference Architecture: Acceleration
SPDY and Web Acceleration cannot be used together
If I enable both a SPDY and Web Acceleration profile on a Virtual Server, the initial html page is downloaded but all subsequent HTTP requests (javascript, css, images etc.) return with size 0 and response status 0. If I switch off either of them then it seems to work fine. Has anyone else encountered this? Platform: BIG-IP 11.5.0 Build 1.0.227 Hotfix HF1
SPDY not working with Chrome browser on Android
Hi, we're experimenting with SPDY profiles on LTM 11.4 SPDY seems to be working fine with spdy-enabled desktop browsers (Chrome, Firefox) and also with non-spdy browsers (IE, iPhone?) The only browser, which can't get a connection to an spdy-enabled virtual server is Google Chrome on Android. There we get "ERR_CONNECTION_CLOSED" on the client. On a tcpdump, the SSL-handshake seems ok, but then the loadbalancer ends the connection (FIN). Might be a browser bug (though since Google invented SPDY, one would think SPDY on Google Chrome should be flawless). Has anybody experienced the same, has any hints or can at least confirm this? LTM: 11.4.1 Browser: Android Chrome 35.0.1916.138 Thank you in advance, Markus
Ready or not, HTTP 2.0 is here
From HTTP to SPDY, to HTTP 2.0. The introduction of a new protocol optimized for today’s evolving web services opens the door to a world of possibilities. But are you ready to make this change? While the breakneck speed with which applications, devices and servers are evolving is common knowledge, few are aware that the HTTP protocol, such a key part of the modern internet, has seen only a few changes of significance since its inception. HTTP – behind the times? According to the Internet Engineering Task Force (IETF), HTTP 1.0 was first officially introduced in 1996. The following version, HTTP 1.1, and the version most commonly used to this day was officially released in 1997. 1997! And we’re still using it! To give you some idea of how old this makes HTTP 1.1 in terms of the development of the internet - in 1997 there was no Google! There was no Paypal ! It goes without saying, of course, that since 1997, both the internet and the amount of traffic it has to handle have grown enormously. Standardization of HTTP 2.0 by the IETF is scheduled for 2015. It’s unrealistic to expect most businesses to immediately deploy HTTP 2.0 in their organizations. However seeing the clear benefits of HTTP 2.0, which is to enable infrastructure to handle huge volume of traffic to access applications and services, many organizations will soon implement this new protocol. F5: Ready for SPDY, ready for HTTP 2.0 The initial draft of HTTP 2.0 was based on the SPDY protocol. When SPDY was first introduced some years ago, the first company to provide a solution to enable businesses to “switch over” to SPDY was F5, we introduced a SPDY Gateway then. SPDY Gateway allowed our enterprise customers to overcome the biggest hurdle in the transition to adopt SPDY protocol on the server end, with the stable and secure ADC and gateway services of BIG-IP. Organizations have the option to make servers upgrade to support the protocol, or use the gateway to handle the connection. This gives businesses the time necessary to make a smooth and gradual transition from HTTP 1.0 to SPDY on the server side. SPDY Gateway is just one example of the many ways ADC can contribute to a flexible and agile infrastructure for businesses. One of the well-known ADC use case in SPDY protocol is SSL termination. Similarly in the transition to HTTP 2.0, a HTTP 2.0 gateway will help organizations plan their adoption and migration to accommodate demands of HTTP 2.0. Thinking ahead F5 is always in the forefront of technology evolution. HTTP 2.0 Gateway is just one example of F5’s dedication in the evolution of Application Delivery technology, providing guidance to our customers making transitions to new technology as simple as possible. Currently, F5’s BIG-IP supports HTTP 2.0 under our early access program. We expect its general availability after HTTP 2.0 standardization is completed in 2015. For a Japanese version of this post, please go here.
