When writing an HTTP server or client in Go, timeouts are amongst the easiest and most subtle things to get wrong: there’s many to choose from, and a mistake can have no consequences for a long time, until the network glitches and the process hangs.
HTTP is a complex multi-stage protocol, so there's no one-size fits all solution to timeouts. Think about a streaming endpoint versus a JSON API versus a Comet endpoint. Indeed, the defaults are often not what you want.
In this post I’ll take apart the various stages you might need to apply a timeout to, and look at the different ways to do it, on both the Server and the Client side.
First, you need to know about the network primitive that Go exposes to implement timeouts: Deadlines.
Exposed by net.Conn
with the Set[Read|Write]Deadline(time.Time)
methods, Deadlines are an absolute time which when reached makes all I/O operations fail with a timeout error.
Deadlines are not timeouts. Once set they stay in force forever (or until the next call to SetDeadline
), no matter if and how the connection is used in the meantime. So to build a timeout with SetDeadline
you'll have to Continue reading
We launched DNSSEC late last year and are already signing 56.9 billion DNS record sets per day. At this scale, we care a great deal about compute cost. One of the ways we save CPU cycles is our unique implementation of negative answers in DNSSEC.
CC BY-SA 2.0 image by Chris Short
I will briefly explain a few concepts you need to know about DNSSEC and negative answers, and then we will dive into how CloudFlare saves on compute when asked for names that don’t exist.
Here’s a quick summary of DNSSEC:
This is an unsigned DNS answer (unsigned == no DNSSEC):
cloudflare.com. 299 IN A 198.41.214.162
cloudflare.com. 299 IN A 198.41.215.162
This is an answer with DNSSEC:
cloudflare.com. 299 IN A 198.41.214.162
cloudflare.com. 299 IN A 198.41.215.162
cloudflare.com. 299 IN RRSIG A 13 2 300 20160311145051 20160309125051 35273 cloudflare.com. RqRna0qkih8cuki++YbFOkJi0DGeNpCMYDzlBuG88LWqx+Aaq8x3kQZX TzMTpFRs6K0na9NCUg412bOD4LH3EQ==
Answers with DNSSEC contain a signature for every record type that is returned. (In this example, only A records are returned so there is only one signature.) The signatures allow Continue reading
We would like to share more details with our customers and readers on the internet outages that occurred this morning and earlier in the week, and what we are doing to prevent these from happening again.
On June 17, at 08:32 UTC, our systems detected a significant packet loss between multiple destinations on one of our major transit provider backbone networks, Telia Carrier.
In the timeframe where the incident was being analysed by our engineers, the loss became intermittent and finally disappeared.
Today, Jun 20, at 12:10 UTC, our systems again detected massive packet loss on one of our major transit provider backbone networks: Telia Carrier.
Typically, transit providers are very reliable and transport all of our packets from one point of the globe to the other without loss - that’s what we pay them for. In this case, our packets (and that of other Telia customers), were being dropped.
While Internet users usually take it for granted that they can reach any destination in the world from their homes and businesses, the reality is harsher than that. Our planet is big, and Continue reading
CloudFlare and Gandi have been hosting a speaker series on DNS, previously bringing in the founder of DNS Paul Mockapetris and Dan Kaminsky, who uncovered one of the most critical vulnerabilities in DNS.
Our third and final talk is coming up on June 21st at 6PM PST at the Gandi office in San Francisco (live stream link will be posted on the Meetup page) and you won’t want to miss it, because our speaker is none other than Paul Vixie.
Paul wrote most of BIND Version 8 and hired the team who wrote BIND Version 9, the most widely used DNS software on the Internet. He founded ISC, home of BIND and F-root and later operated C-root.
We'll talk about alternative DNS root servers, email security and spam (Paul founded the first ever anti-spam company), and what needs to be done about DNS and security (Paul added most of BIND’s current security systems).
So come grab a beer and let's geek out about DNS one more time.
Здравствуйте! ))) CloudFlare is excited to announce the newest addition to our network in the largest country in the world (by footprint), increasing both our data center and city count to 83. Moscow is not only the capital and largest city in Russia, it is also home to several Internet exchanges which CloudFlare now participates at: the Moscow Internet Exchange (MSK-IX), Data IX and Global IX (Eurasia Peering coming soon). This raises the number of exchanges that CloudFlare is a participant of to over 120, making us one of the top interconnected networks globally.
Здравствуйте! ))) Мы рады объявить о новом пополнении в нашей сети network в самой большой стране мира (по занимаемой площади), увеличивая как количество наших датацентров, так и количество городов на 83. Москва является не только столицей и самым крупным городом в России, но она также является домом для нескольких точек обмена интернет-трафиком. CloudFlare в настоящее время принимает участие в следующих: Moscow Internet Exchange (MSK-IX), Data IX и Global IX (Eurasia Peering на подходе). Это увеличивает количество точек обмена интернет-трафиком, в которых участвует CloudFlare до 120, тем самым продвигая нас на одну из лидирующих позиций наиболее взаимосвязаных сетей в мире.
Hello from the Mile High City! Denver is our twelfth data center in the United States, and our 82nd data center globally, improving regional web performance.
Near the iconic Rocky Mountains, Denver brews more beer than any other American city, and is home to a thriving technology and entrepreneurship community. The Colorado community brought us companies such as Chipotle, HomeAdvisor, and LogRhythm - and is helping build the next great Colorado company.
Despite having a unique place on the map of the United States, and it's significant distance from other cities (900 miles to Dallas; 1,000 miles to Chicago, 1,000 miles to Los Angeles), Denver has not always been a major point of regional interconnection. Through the efforts of the community, and greater localized peering of traffic, this is changing for the better.
Visitors to millions of websites using ISPs, big or small, such as Aerux, Blackfoot, Comcast and CenturyLink, should see a 2x increase in performance, as they are now served from our Denver data center.
CloudFlare participates at two major internet exchanges: Any2 Denver and IX-Denver.
GitHub offers a web hosting service whereby you can serve a static website from a GitHub repository. This platform, GitHub Pages, can be used with CloudFlare whilst using a custom domain name.
In this tutorial, I will show you how to use CloudFlare and GitHub together. By taking advantage of CloudFlare’s global network, you can utilise our CDN service to improve your site's performance and security.
Whilst GitHub Pages doesn't ordinarily support SSL on custom domains, CloudFlare's Universal SSL allows your users to access your site over SSL, thus opening up the performance advantages of HTTP/2.
GitHub Pages is designed to host sites that only serve static HTML. The ability to only host static content isn’t as big of a restriction as you might think.
Static site generators avoid repetitive update tasks of updating “latest posts” feeds, pagination or sitemaps; whilst generating static HTML that can be uploaded to any web hosting service without a scripting engine. Unlike ancient desktop tools like FrontPage and Dreamweaver which lacked a content model, modern static site generators have the design decisively separate from content.
Typically, CMS-based sites must query a database for content, then render the HTML to be served to the end Continue reading
Our week begins in Brussels, where we announce our newest data center. This is our 23rd data center in Europe alone, and our 81st data center globally - providing additional redundancy to nearby facilities in Amsterdam and Paris.
Millions of websites using CloudFlare are now faster in Brussels, and we are excited to exchange traffic at the Belgium National Internet Exchange (BNIX).
Brussels - which hosts several strategic European institutions such as the European Commission and the Council of the European Union - is home to over 40,000 EU employees. With the turn up of our Brussels data center, they join the rest of the country in experiencing a faster Internet. Impressively, close to 90% of Belgium's citizens are online.
We will be announcing two more data centers this week - each in one of the world’s most populous countries. Could you guess which ones?
The layered nature of the Internet (HTTP on top of some reliable transport (e.g. TCP), TCP on top of some datagram layer (e.g. IP), IP on top of some link (e.g. Ethernet)) has been very important in its development. Different link layers have come and gone over time (any readers still using 802.5?) and this flexibility also means that a connection from your web browser might traverse your home network over WiFi, then down a DSL line, across fiber and finally be delivered over Ethernet to the web server. Each layer is blissfully unaware of the implementation of the layer below it.
But there are some disadvantages to this model. In the case of TLS (the most common standard used for sending encrypted data across in the Internet and the protocol your browser uses with visiting an https:// web site) the layering of TLS on top of TCP can cause delays to the delivery of a web page.
That’s because TLS divides the data being transmitted into records of a fixed (maximum) size and then hands those records to TCP for transmission. TCP promptly divides those records up into segments which are then transmitted. Ultimately, Continue reading
CloudFlare is excited to announce the launch of our newest data center in Perth, Australia. This expands the breadth of our global network to span 80 unique cities across 41 countries, and is our fourth data center in the Oceania region, joining existing data centers in Sydney, Melbourne and Auckland.
Perth is in a fascinating location. Home to sunny beaches and the highest number of self-made millionaires in the world, it is actually geographically closer to Singapore than to Sydney (though closer to Sydney in a “networking” sense, as determined by BGP routing).
Visitors to millions of websites across Western Australia served locally can now experience a faster and safer Internet - and ISPs can reach us at the Western Australia Internet Exchange (WA-IX), one of 119 internet exchanges that we openly peer at.
Late last year, the CloudFlare UI team made a huge decision: to change JavaScript frameworks from Backbone & Marionette to React & Redux.
We’ve been one of the single biggest Backbone+Marionette apps on the web for a while now, and the decision to move was not taken lightly. On our team we have a former core team member of the Marionette team (myself), and the author of several popular Backbone projects: Backgrid and Backbone Paginator.
In the spirit of the open web, we want to share more about what we’re doing. This starts by open sourcing the UI framework that we have spent the last few months building.
While moving to React, we’ve taken our existing Backbone UI framework and rebuilt it from scratch on top of React. This includes over 50 packages that include dozens of components, utilities, test helpers, and more.
Examples: https://cloudflare.github.io/cf-ui
GitHub: https://github.com/cloudflare/cf-ui
We’re not open sourcing cf-ui because we think our buttons are any better than anyone else’s buttons, but because it’s an opportunity to share some of the technical decisions that we’ve made while building out a massive React application. The hope is that this will be Continue reading
Early last month Apple announced that all apps submitted to the Apple Store June 1 forward would need to support IPv6-only networking as they transition to IPv6-only network services in iOS 9. Apple reports that “Most apps will not require any changes”, as these existing apps support IPv6 through Apple's NSURLSession and CFNetwork APIs.
Our goal with IPv6, and any other emerging networking technology, is to make it ridiculously easy for our customers to make the transition. Over 2 years ago, we published Eliminating the last reasons to not enable IPv6 in celebration of World IPv6 Day. CloudFlare has been offering full IPv6 support as well as our IPv6-to-IPv4 gateway to all of our customers since 2012.
IPv4 represents a technical limitation, a hard stop to the number of devices that can access the Internet. When the Internet Protocol (IP) was first introduced by Vint Cerf and Bob Kahn in the late 1970s, Internet Protocol Version 4 (IPv4) used a 32-bit (four-byte) number, allowing about 4 billion unique addresses. At the time, IPv4 seemed more than sufficient to power the World Wide Web. On January 31, 2011, the top-level pool of Internet Assigned Numbers Authority Continue reading
From time to time a customer writes in and asks about certain requests that have been blocked by the CloudFlare WAF. Recently, a customer couldn’t understand why it appeared that some simple GET requests for their homepage were listed as blocked in WAF analytics.
A sample request looked liked this:
GET / HTTP/1.1
Host: www.example.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (compatible; MSIE 11.0; Windows NT 6.1; Win64; x64; Trident/5.0)'+(select*from(select(sleep(20)))a)+'
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,fr;q=0.6
As I said, a simple request for the homepage of the web site, which at first glance doesn’t look suspicious at all. Unless your take a look at the User-Agent
header (its value is the string that identifies the browser being used):
Mozilla/5.0 (compatible; MSIE 11.0; Windows NT 6.1; Win64; x64; Trident/5.0)'+(select*from(select(sleep(20)))a)+
The start looks reasonable (it’s apparently Microsoft Internet Explorer 11) but the agent strings ends with '+(select*from(select(sleep(20)))a)+
. The attacker is attempting a SQL injection inside the User-Agent
value.
It’s common to see SQL injection in URIs and form parameters, but here the attacker has hidden the SQL query select * from (select(sleep(20)))
inside the User-Agent
Continue reading
Two weeks ago CloudFlare announced that it was supporting HTTP/2 Server Push for all our customers. By simply adding a Link
header to an HTTP response specifying preload
CloudFlare would automatically push items to web browsers that support Server Push.
To illustrate how easy this is I create a small PHP page that uses the PHP header
function to insert appropriate Link
headers to push images to the web browser via CloudFlare. The web page looks like this when loaded:
There are two images loaded from the same server both of which are pushed if the web browser supports Server Push. This is achieved by inserting two Link
headers in the HTTP response. The response looks like:
HTTP/1.1 200 OK
Server: nginx/1.9.15
Date: Fri, 13 May 2016 10:52:13 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Link: </images/drucken.jpg>; rel=preload; as=image
Link: </images/empire.jpg>; rel=preload; as=image
At the bottom are the two Link
headers corresponding to the two images on the page with the rel=preload
directive as specified in W3C preload draft.
The complete code can be found in this gist but the core of the code looks like this:
<?php
function pushImage($uri) {
header("Link: <{$uri}>; rel=preload; Continue reading
In December, we released HTTP/2 support for all customers and on April 28 we released HTTP/2 Server Push support as well.
The release of HTTP/2 by CloudFlare had a huge impact on the number of sites supporting and using the protocol. Today, 50% of sites that use HTTP/2 are served via CloudFlare.
When we released HTTP/2 support we decided not to deprecate SPDY immediately because it was still in widespread use and we promised to open source our modifications to NGINX as it was not possible to support both SPDY and HTTP/2 together with the standard release of NGINX.
We've extracted our changes and they are available as a patch here. This patch should build cleanly against NGINX 1.9.7.
The patch means that NGINX can be built with both --with-http_v2_module
and --with-http_spdy_module
. And it will accept both the spdy
and http2
keywords to the listen
directive.
To configure both HTTP/2 and SPDY in NGINX you'll need to run:
./configure --with-http_spdy_module --with-http_v2_module --with-http_ssl_module
Note that you need SSL support for both SPDY and HTTP/2.
Then it will be possible to configure an NGINX server to support both HTTP/2 and SPDY on Continue reading
At CloudFlare we strive to combine features that are simple, secure, and backed by solid technology. The Origin CA is a great example of this. You no longer need to go to a third-party certificate authority to protect the connection between CloudFlare and your origin server. You can now get a certificate to encrypt the connection between CloudFlare and the origin from CloudFlare directly with one click.
In certificate-based security, the most important thing is protecting the private key. We designed the one-click certificate dashboard to maximize private key security. Your private key is created client-side in your browser using the W3C’s Web Crypto API and only the public key is sent to CloudFlare’s servers. This security feature turned out to be a big win for usability as well as an interesting technical challenge.
Most certificate authorities (CAs) specialize in one type of transaction: they take a certificate signing request (CSR) (and sometimes a fee) and in return they provide a signed certificate. A CSR is a way to tell a certificate authority what your public key is and to prove you have control of the corresponding private key. The certificate authority doesn’t Continue reading
Very early on in the company’s history we decided that everything that CloudFlare does on behalf of its customer-base should be controllable via an API. In fact, when you login to the CloudFlare control panel, you’re really just making API calls to our backend services. Over time that API has matured and improved. We are now on v4 of that API.
The current CloudFlare API is documented here and it’s used by both the CloudFlare control panel and directly by umpteen customers every minute of every day. The new API is designed with a clean naming structure and consistent data representation for data. It’s also extensible.
This blog entry introduces python-cloudflare, a Python wrapper providing full access to the CloudFlare v4 API.
Let’s get right into the thick-of-it with the simplest coding example available to show python-cloudflare in action. This example lists all your domains (zones) and also checks some basic features for each zone.
#!/usr/bin/env python
import CloudFlare
def main():
cf = CloudFlare.CloudFlare()
zones = cf.zones.get(params={'per_page':50})
for zone in zones:
zone_name = zone['name']
zone_id = zone['id']
settings_ipv6 = cf.zones.settings.ipv6.get(zone_id)
ipv6_on = settings_ipv6['value']
Continue reading
Today we’re announcing the sunsetting of CloudFlare’s first client API, API v1. Starting November 9th, 2016 at noon Pacific Time (20:00 UTC), CloudFlare will no longer be supporting API v1.
While it is bittersweet to let our first API from CloudFlare’s early days go, we are so excited to show you all of the great things about our latest API: API v4. We’re confident that once you get started using it, you’ll see how easy API v4 makes managing your CloudFlare settings.
(For those of you who are curious where CloudFlare’s API v2 and v3 went, they ran away with IPv5 and PHP 6.)
If you are using API v1 and need to migrate to API v4, we’ve written extensive migration docs here for you to follow. They contain every API call from v1 and their equivalent in v4 side by side.
After CloudFlare discontinues support for API v1 in November 2016, any calls to API v1 will return the HTTP status code 410 Gone with the message: “This API has been deprecated in favor of API v4, available at https://api.cloudflare.com.”
CloudFlare uses Continue reading
Last week multiple vulnerabilities were made public in the popular image manipulation software, ImageMagick. These were quickly named ImageTragick. Although a vulnerability in image manipulation software might not seem like a problem for web site owners it is in fact a genuine security concern.
CloudFlare quickly rolled out a WAF rule to protect our customers from this vulnerability. It was automatically deployed for all customers with the WAF enabled. We know that it takes time for customers to upgrade their web server software and so the WAF protects them in the interim.
Many websites allow users to upload images and the websites themselves often manipulate these images using software like ImageMagick. For example, if you upload a picture of yourself to use as an avatar, it will very likely be resized by the website. ImageMagick is very popular and there are plugins that make it easy to use with PHP, Ruby, Node.js and other languages so it is common for websites to use it for image resizing or cropping.
Unfortunately, researchers discovered that it was possible to execute arbitrary code (CVE-2016-3714) by hiding it inside image files that a user uploads. That means an attacker can make Continue reading
On March 9, 章亦春, known to most of us as agentzh, organized the first Bay Area OpenResty Meetup at CloudFlare's San Francisco office.
CloudFlare is a big user of Lua, LuaJIT, NGINX and OpenResty and happy to be able to sponsor Yichun's work on this fast, flexible platform.
The slides and videos from the meetup are now available for viewing by people who were unable to be there in person.
The slides are here.
The slides can be found here
Yichun's slides are here
If you are interested in being present at the next OpenResty Meetup by sure to follow the meetup itself.