Introducing Direct Uploads for Cloudflare Pages
With Pages, we are constantly looking for ways to improve the developer experience. One of the areas we are keen to focus on is removing any barriers to entry for our users regardless of their use case or existing set up. Pages is an all-in-one solution with an automated Continuous Integration (CI) pipeline to help you build and deploy your site with one commit to your projects’ repositories hosted on GitHub or GitLab.
However, we realize that this excluded repositories that used a source control provider that Pages didn’t yet support and required varying build complexities. Even though Pages continues to build first-class integrations – for example, we added GitLab support in November 2021 – there are numerous providers to choose from, some of which use `git` alternatives like SVN or Mercurial for their version control systems. It’s also common for larger companies to self-host their project repositories, guarded by a mix of custom authentication and/or proxy protocols.
Pages needed a solution that worked regardless of the repository’s source location and accommodate build project’s complexity. Today, we’re thrilled to announce that Pages now supports direct uploads to give you more power to build and iterate how you want and with Continue reading
IPv6 Unique Local Addresses (ULA) Made Useless
Recent news from the Department of Unintended Consequences: RFC 6724 changed the IPv4/IPv6 source/destination address selection rules a decade ago, and it seems that the common interpretation of those rules makes IPv6 Unique Local Addresses (ULA) less preferred than the IPv4 addresses, at least according to the recent Unintended Operational Issues With ULA draft by Nick Buraglio, Chris Cummings and Russ White.
End result: If you use only ULA addresses in your dual-stack network1, IPv6 won’t be used at all. Even worse, if you use ULA addresses together with global IPv6 addresses (GUA) as a fallback mechanism, there might be hidden gotchas that you won’t discover until you turn off IPv4. Looks like someone did a Truly Great Job, and ULA stands for Useless Local Addresses.
IPv6 Unique Local Addresses (ULA) Made Useless
Recent news from the Department of Unintended Consequences: RFC 6724 changed the IPv4/IPv6 source/destination address selection rules a decade ago, and it seems that the common interpretation of those rules makes IPv6 Unique Local Addresses (ULA) less preferred than the IPv4 addresses, at least according to the recent Unintended Operational Issues With ULA draft by Nick Buraglio, Chris Cummings and Russ White.
End result: If you use only ULA addresses in your dual-stack network1, IPv6 won’t be used at all. Even worse, if you use ULA addresses together with global IPv6 addresses (GUA) as a fallback mechanism, there might be hidden gotchas that you won’t discover until you turn off IPv4. Looks like someone did a Truly Great Job, and ULA stands for Useless Local Addresses.
Come join us at Cloudflare Connect New York this Thursday!
We take a break from Platform Week to share big news – we’re going to New York this week for our Cloudflare Connect customer event.
We’re packing our bags, getting on planes and heading to New York to do our first live customer event since 2019 and we could not be more excited. It is time with you – the people building, delivering and securing the apps and networks we know and trust – that are the inspiration for the innovation we deliver. We can’t wait to spend time with you.
Our co-founder and CEO Matthew Prince will kick off the day with his view from the top. We’ll then be breaking out into focused conversations to dig in on our latest product news and roadmaps.
Excited about what we’re talking about for Platform Week? Come chat with the Workers team in person and hear more about the roadmap.
Intrigued by the latest DDoS stats we posted and want to learn more? Meet with the team analyzing the attacks and learn about where we go from here.
Not sure where to start your Zero Trust journey? We’ll talk you through what we’re seeing and introduce you to other customers who Continue reading
Tech Bytes: How Nokia’s Digital Sandbox Enhances Intent-Based Automation (Sponsored)
Today on the Tech Bytes podcast we dive into sponsor Nokia's Digital Sandbox, which creates a real-time model of a data center network by extracting state and configuration from leaf and spine switches. Network engineers can use this model to test and validate changes. We discuss how the sandbox works and how it ties into Nokia's approach to intent-based networking.
The post Tech Bytes: How Nokia’s Digital Sandbox Enhances Intent-Based Automation (Sponsored) appeared first on Packet Pushers.
Tech Bytes: How Nokia’s Digital Sandbox Enhances Intent-Based Automation (Sponsored)
Today on the Tech Bytes podcast we dive into sponsor Nokia's Digital Sandbox, which creates a real-time model of a data center network by extracting state and configuration from leaf and spine switches. Network engineers can use this model to test and validate changes. We discuss how the sandbox works and how it ties into Nokia's approach to intent-based networking.BGP Policy (Part 7)
At the most basic level, there are only three BGP policies: pushing traffic through a specific exit point; pulling traffic through a specific entry point; preventing a remote AS (more than one AS hop away) from transiting your AS to reach a specific destination. In this series I’m going to discuss different reasons for these kinds of policies, and different ways to implement them in interdomain BGP.
In this post—the last post in this series—I’m going to cover do not transit options from the perspective of AS65001 in the following network—
There are cases where an operator does not traffic to be forwarded to them through some specific AS, whether directly connected or multiple hops away. For instance, AS65001 and AS65005 might be operated by companies in politically unfriendly nations. In this case, AS65001 may be legally required to reject traffic that has passed through the nation in which AS65005 is located. There are at least three mechanisms in BGP that are used, in different situations, to enforce this kind of policy.
Do Not Advertise Communities (Provider Specific)
Many providers supply communities a customer can use to block the advertisement of their routes to a particular AS. For instance, if Continue reading
Network Break 381: TLS Vulnerability Affects Aruba, Avaya Switches; Cisco Teases Predictive Networks
Take a Network Break! This week we cover a vulnerable implementation of a TLS module that affects switches from HPE Aruba and Extreme Networks' Avaya brand, Cisco teases a forthcoming technology called Predictive Networks that promises analytics and automated problem-solving, Fortinet announces new firewalls, and more IT news.A Community Group for Web-interoperable JavaScript runtimes
Today, Cloudflare – in partnership with Vercel, Shopify, and individual core contributors to both Node.js and Deno – is announcing the establishment of a new Community Group focused on the interoperable implementation of standardized web APIs in non-web browser, JavaScript-based development environments.
The W3C and the Web Hypertext Application Technology Working Group (or WHATWG) have long pioneered the efforts to develop standardized APIs and features for the web as a development environment. APIs such as fetch(), ReadableStream and WritableStream, URL, URLPattern, TextEncoder, and more have become ubiquitous and valuable components of modern web development. However, the charters of these existing groups have always been explicitly limited to considering only the specific needs of web browsers, resulting in the development of standards that are not readily optimized for any environment that does not look exactly like a web browser. A good example of this effect is that some non-browser implementations of the Streams standard are an order of magnitude slower than the equivalent Node.js streams and Deno reader implementations due largely to how the API is specified in the standard.
Serverless environments such as Cloudflare Workers, or runtimes like Node.js and Deno, have Continue reading
Cloudflare and StackBlitz partner to deliver an instant and secure developer experience
We are starting our Platform Week focused on the most important aspect of a developer platform — developers. At the core of every announcement this week is developer experience. In other words, it doesn’t matter how groundbreaking the technology is if at the end of the day we’re not making your job as a developer easier.
Earlier today, we announced the general availability of a new Wrangler version, making it easier than ever to get started and develop with Workers. We’re also excited to announce that we’re partnering with StackBlitz. Together, we will bring the Wrangler experience closer to you – directly to your browser, with no dependencies required!
StackBlitz is a web-based code editor provided with a fresh and fast development environment on each page load. StackBlitz’s development environments are powered by WebContainers, the first WebAssembly-based operating system, which boots secure development environments entirely within your browser tab.
Introducing new Wrangler, running in your browser
One of the Wrangler improvements we announced today is the option to easily run Wrangler in any Node.js environment, including your browser which is now powered by WebContainers!
StackBlitz’s WebContainers are optimized for starting any project within seconds, including the installation of Continue reading
10 things I love about Wrangler v2.0
Last November, we announced the beta release of a full rewrite of Wrangler, our CLI for building Cloudflare Workers. Since then, we’ve been working round the clock to make sure it's feature complete, bug-free, and easy to use. We are proud to announce that Wrangler goes public today for general usage, and can’t wait to see what people build with it!
Rewrites can be scary. Our goal for this version of Wrangler was backward compatibility with the original version, while significantly improving the developer experience. I'd like to take this opportunity to present 10 reasons why you should upgrade to the new Wrangler!
1. It's simpler to install:
Previously, folks would have to install @cloudflare/wrangler globally on a system. This made it hard to use different versions of Wrangler across projects. Further, it was hard to install on some CI systems because of lack of access to a user's root folder. Sometimes, folks would forget to add the @cloudflare scope when installing, confusing them when a completely unrelated package was installed and didn't work as expected.
Let's fix that. We've simplified this by now publishing to the wrangler package, so you can run npm Continue reading
Open source Managed Components for Cloudflare Zaraz
In early 2020, we sat down and tried thinking if there’s a way to load third-party tools on the Internet without slowing down websites, without making them less secure, and without sacrificing users’ privacy. In the evening, after scanning through thousands of websites, our answer was “well, sort of”. It seemed possible: many types of third-party tools are merely collecting information in the browser and then sending it to a remote server. We could theoretically figure out what it is that they’re collecting, and then instead just collect it once efficiently, and send it server-side to their servers, mimicking their data schema. If we do this, we can get rid of loading their JavaScript code inside websites completely. This means no more risk of malicious scripts, no more performance losses, and fewer privacy concerns.
But the answer wasn’t a definite “YES!” because we realized this is going to be very complicated. We looked into the network requests of major third-party scripts, and often it seemed cryptic. We set ourselves up for a lot of work, looking at the network requests made by tools and trying to figure out what they are doing – What is this parameter? When is Continue reading
The next chapter for Cloudflare Workers: open source
450,000 developers have used Cloudflare Workers since we launched.
When we announced Cloudflare Workers nearly five years ago, we had no idea if we’d ever be in this position. But a lot of care, hard work — not to mention dogfooding — later, we’ve been absolutely blown away by the use cases and applications built on our developer platform, not to mention the community that’s grown around the product.
My job isn’t just speaking to developers who are already using Cloudflare Workers, however. I spend a lot of time talking to developers who aren’t yet using Workers, too. Despite how cool the tech is — the performance, the ability to just code without worrying about anything else like containers, and the total cost advantages — there are two things that cause developers to hesitate in engaging with us on Workers.
The first: they worry about being locked in. No matter how bullish on the technology you are, if you’re betting the future of a company on a development platform, you don’t want the possibility of being held to ransom. And second: as a developer, you want a local development environment to quickly iterate and test your changes. These concerns might Continue reading