# Internet Engineering Task Force (IETF) The Internet Engineering Task Force (IETF) is the premier Internet standards organization that develops standards and works on networking technologies forming the foundation of the Internet. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## The /3 Body Problem DevFeed: [The /3 Body Problem]() Original publisher: [Read original article]() Author: Remco van Mook Published: 2026-09-10T09:22:46Z Content type: article Language: en Sources: [RIPE Labs]() Topics: [networking](), [Internet](), [Internet Engineering Task Force (IETF)]() Tags: [article](), [ietf](), [internet](), [ipv6](), [networking](), [policy](), [space]() ### AI overview The article examines how IPv6 addressing and policy mechanisms may need to evolve for space networking. It argues that terrestrial assumptions break down beyond low Earth orbit and calls for addressing policy questions now, including through the proposed EXPANSE working group. ### Source excerpt A large chunk of IPv6 is heading for space, and every policy question about it is currently going to be deferred to the RIR communities. This article outlines what those questions look like, and argues why now is the time to start asking them. ## \[Podcast\] Measuring the impact of locally served root zone DevFeed: [\[Podcast\] Measuring the impact of locally served root zone]() Original publisher: [Read original article]() Author: George Michaelson Published: 2026-09-03T01:05:09Z Content type: article Language: en Sources: [APNIC Blog]() Topics: [DNSSEC](), [Network](), [Security](), [Internet Engineering Task Force (IETF)](), [bug]() Tags: [bug](), [dns](), [dnssec](), [ietf](), [measurement](), [network](), [podcast](), [research](), [security](), [standards](), [tech-matters]() ### AI overview This podcast discusses research into locally served root zones, a DNS resolver model that pre-fetches and stores the root zone. The study examined BIND, Unbound, and Knot Resolver across multiple configurations, including in-band retrieval and HTTPS fetching. It identified an Unbound bug and found that root zone updates can generate substantial network traffic, potentially exceeding traffic from more frequent queries for uncached data. ### Source excerpt An analysis of the traffic impacts of locally served root zones, by Ilyas Rahimi at UvA. ## The emerging role of AI in governance discussion DevFeed: [The emerging role of AI in governance discussion]() Original publisher: [Read original article]() Author: George Michaelson Published: 2026-08-26T04:50:50Z Content type: article Language: en Sources: [APNIC Blog]() Topics: [Internet Engineering Task Force (IETF)](), [Large Language Model](), [Artificial Intelligence](), [AI Strategy]() Tags: [ai](), [artificial-intelligence](), [content](), [eu](), [governance](), [ietf](), [large-language-model](), [llm](), [standards](), [tech-matters]() ### AI overview The article examines an ongoing IETF debate over the use and disclosure of LLM-generated text in drafts, standards work, and discussions. It also compares these concerns with EU efforts to promote transparency and labelling of AI-generated or AI-modified content. ### Source excerpt A growing debate within the IETF is exploring how AI-generated content should be used and disclosed in standards discussions. ## AI, IPv6, and the future Internet at IETF 126 DevFeed: [AI, IPv6, and the future Internet at IETF 126]() Original publisher: [Read original article]() Author: Anlei Hu Published: 2026-08-25T01:20:50Z Content type: article Language: en Sources: [APNIC Blog]() Topics: [Internet](), [Internet Engineering Task Force (IETF)](), [networking](), [Artificial Intelligence](), [AI Agent](), [Network](), [Security](), [Latency](), [telemetry]() Tags: [ai](), [dns](), [guest-post](), [ietf](), [infrastructure](), [internet](), [internet-infrastructure](), [ipv6](), [latency](), [low-latency](), [nat](), [network](), [networks](), [opinion](), [security](), [standards](), [tech-matters](), [telemetry]() ### AI overview The article reports on IETF 126 discussions about how AI is shaping Internet infrastructure. It presents IPv6 as important for the scale, globally unique addressing, and traceability required by distributed AI deployments and agents, while DNS remains central to service discovery. It also covers IPv4/IPv6 mapping, NAT-related identity and security concerns, SRv6, low-latency forwarding, IOAM telemetry, and proposals for DNS-based AI agent discovery. ### Source excerpt Guest Post: At IETF 126, discussions highlighted how AI is beginning to shape the future of Internet infrastructure. Participants identified IPv6 as a critical foundation for large-scale AI ecosystems and explored new approaches. ## Worth Reading 081026 DevFeed: [Worth Reading 081026]() Original publisher: [Read original article]() Author: Russ Published: 2026-08-10T19:50:20Z Content type: article Language: en Sources: [rule 11 reader]() Topics: [Artificial Intelligence](), [Open Source Models & Datasets](), [networking](), [Routing (disambiguation)](), [Internet Engineering Task Force (IETF)](), [App]() Tags: [ai](), [ietf](), [open-source](), [routing](), [tech](), [worth-reading]() ### AI overview A roundup of reading topics covering the conflict over open-source AI in U.S. AI companies, a network routing application that checks prefix advertisements against live RIPE RIS data, and communications-protocol standardization discussed at IETF 126. ### Source excerpt There is an interesting fight within the leadership of U.S. AI companies. It is between the supporters of open-source AI and those driven to oppose open-source AI. A Chinese man accused by the communist authorities of having committed "economic crimes" figured that he could evade the long reach of the country's police state by hiding out in plain view: in a stadium packed with 60,000 people listening to a pop concert. The J2SW Prefix Advertisement Checker, my 3rd application in the network series, checks the exact prefix against live routing data and reports the origin ASN seen by RIPE RIS collectors. A growing number of drivers are pushing back against increasingly tech-heavy vehicles, saying they prefer the simplicity of a The IETF does not launch rockets, or design spacecraft, or even work on radio systems and spectrum assignment, but it has been engaged in the standardisation of communications protocols used to communicate with these spacecraft. Here's a few topics that were presented at IETF 126. ## SCIM Deprovisioning Is a Promise Your App Probably Breaks DevFeed: [SCIM Deprovisioning Is a Promise Your App Probably Breaks]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-06T01:29:36Z Content type: article Language: en Sources: [WorkOS Blog]() Topics: [Security](), [API](), [HTTP](), [JSON](), [Internet Engineering Task Force (IETF)](), [Protocol (disambiguation)]() Tags: [api](), [http](), [identity](), [idp](), [ietf](), [json](), [net-conf](), [protocol](), [schema](), [security](), [standards](), [state](), [token]() ### AI overview This article explains that SCIM deprovisioning updates identity state but does not automatically invalidate an application's sessions, refresh tokens, or API keys. It describes how identity providers commonly use soft deactivation and why applications must explicitly handle the resulting offboarding state. ### Source excerpt SCIM tells you a user is gone, but sessions, refresh tokens, and API keys often outlive deprovisioning. Here's why offboarding needs more than a user row. ## Worth Reading 072826 DevFeed: [Worth Reading 072826]() Original publisher: [Read original article]() Author: Russ Published: 2026-07-28T10:59:47Z Content type: article Language: en Sources: [rule 11 reader]() Topics: [Internet](), [data](), [Internet Engineering Task Force (IETF)](), [Networks](), [5G](), [Machine learning]() Tags: [5g](), [ai](), [arp](), [article](), [data](), [ietf](), [internet](), [ipv6](), [networks](), [worth-reading]() ### AI overview A developer reading roundup covering Internet infrastructure, synchronization of replicated data, IPv6-only networking, IPv4 dependencies, ARP, an IETF proposal, 5G control-plane timers, modern machine-learning pipelines, and the integration of AI into everyday applications. ### Source excerpt Today's Internet runs on a vast infrastructure of replicated data, and the difference between order and chaos lies in maintaining consistency through synchronization across the many distributed points where that data is published. IPv6-only networks often still depend on IPv4 subnets and ARP. This article introduces an IETF proposal to eliminate both. Traditional software engineering approaches reliability as a binary state of uptime and downtime. Modern ML pipelines render this paradigm obsolete. Yet while the radios and protocols largely reuse terrestrial 5G designs, one small but crucial component has been left behind: The control plane timers that quietly govern how registration, mobility, and session procedures behave under real-world conditions. Apparently, nearly all of them have reached the same conclusion. I don't merely need AI occasionally. I need it waiting inside every search bar, messaging app, music player, and document reader I already use. ## Chrome develops Merkle Tree Certificates for quantum-resistant HTTPS DevFeed: [Chrome develops Merkle Tree Certificates for quantum-resistant HTTPS]() Original publisher: [Read original article]() Author: Google (noreply@blogger.com) Published: 2026-02-27T17:01:00Z Content type: release Language: en Sources: [Google Online Security]() Topics: [Chrome](), [Post-quantum cryptography](), [Certificate Transparency](), [Internet Engineering Task Force (IETF)](), [TLS (Transport Layer Security)](), [Scalability](), [Security](), [Cryptography]() Tags: [certificate-transparency](), [chrome](), [ietf](), [none](), [post-quantum-cryptography](), [scalability](), [security](), [tls](), [web]() ### AI overview Chrome is developing Merkle Tree Certificates with partners through the IETF PLANTS working group to support quantum-resistant HTTPS while reducing the bandwidth and performance costs of larger post-quantum certificate chains. Chrome says it has no immediate plan to add traditional post-quantum X.509 certificates to the Chrome Root Store and is experimenting with MTCs using real internet traffic. ### Source excerpt Posted by Chrome Secure Web and Networking Team Today we're announcing a new program in Chrome to make HTTPS certificates secure against quantum computers. The Internet Engineering Task Force (IETF) recently created a working group, PKI, Logs, And Tree Signatures ("PLANTS"), aiming to address the performance and bandwidth challenges that the increased size of quantum-resistant cryptography introduces into TLS connections requiring Certificate Transparency (CT). We recently shared our call to action to secure quantum computing and have written about challenges introduced by quantum-resistant cryptography and some of the steps we've taken to address them in earlier blog posts. To ensure the scalability and efficiency of the ecosystem, Chrome has no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store. Instead, Chrome, in collaboration with other partners, is developing an evolution of HTTPS certificates based on Merkle Tree Certificates (MTCs), currently in development in the PLANTS working group. MTCs replace the heavy, serialized chain of signatures found in traditional PKI with compact Merkle Tree proofs. In this model, a Certification Authority (CA) signs a single "Tree Head" representing potentially millions of certificates, and the "certificate" sent to the browser is merely a lightweight proof of inclusion in that tree. Why MTCs? MTCs enable the adoption of robust post-quantum algorithms without incurring the massive bandwidth penalty of classical X.509 certificate chains. They also decouple the security strength of the corresponding cryptographic algorithm from the size of the data transmitted to the user. By shrinking the authentication data in a TLS handshake to the absolute minimum, MTCs aim to keep the post-quantum web as fast and seamless as today's internet, maintaining high performance even as we adopt stronger security. Finally, with MTCs, transparency is a fundamental property of issuance: ## JWT Authorization Grant and Identity Chaining in Keycloak 26.5 DevFeed: [JWT Authorization Grant and Identity Chaining in Keycloak 26.5]() Original publisher: [Read original article]() Author: Giuseppe Graziano Published: 2026-01-23T00:00:00Z Content type: article Language: en Sources: [Keycloak Blog]() Topics: [JSON Web Tokens](), [Keycloak](), [OAuth 2.0](), [OAuth](), [Authorization](), [Internet Engineering Task Force (IETF)]() Tags: [authorization](), [deprecated](), [external](), [identity](), [idm](), [jwt](), [kerberos](), [keycloak](), [ldap](), [oauth](), [oauth-2-0](), [openid-connect](), [preview](), [saml](), [sso](), [standard](), [trust]() ### AI overview Keycloak 26.5 introduces preview support for JWT Authorization Grant under RFC 7523. The feature lets clients exchange a signed JWT from an external issuer for a Keycloak access token. The article also explains how combining this grant with OAuth 2.0 Token Exchange can preserve identity and authorization context across multiple trust domains. ### Source excerpt Modern applications and AI agents increasingly operate across distributed trust domains, where each domain is protected by its own OAuth 2.0 Authorization Server. A single request may also traverse multiple resource servers to complete a task. This raises an important challenge: every protected resource must understand who initiated the request, which authorization was granted, and optionally which other resources were accessed before making an authorization decision. Preserving this information across domains is critical. Keycloak 26.5 introduces preview support for the new feature JWT Authorization Grant, implementing RFC 7523. This feature allows a client to present a signed JWT from an external issuer and obtain a Keycloak access token, providing a standard and secure way to authorize requests based on external assertions. However, exchanging a token alone does not fully solve the problem of propagating identity and authorization context across multiple trust domains. The IETF draft OAuth Identity and Authorization Chaining Across Domains defines a standardized flow that combines JWT Authorization Grant (RFC 7523) with OAuth 2.0 Token Exchange (RFC 8693), which Keycloak already supports, to preserve the original user's identity, claims, and authorization throughout the chain. JWT Authorization Grant The JWT Authorization Grant feature allows a client to present a signed JWT assertion to the token endpoint and obtain an access token without an interactive authorization step. To initiate this flow, the client sends a request to the token endpoint with the grant_type set to urn:ietf:params:oauth:grant-type:jwt-bearer and the external token passed in the assertion parameter. It provides a standard and secure alternative to the preview feature External-to-Internal Token Exchange V1 which will be deprecated. Trust relationships in Keycloak are defined through Identity Providers. The JWT Authorization Grant can be enabled and configured in a dedicated section of the ex ## HTTP RateLimit headers DevFeed: [HTTP RateLimit headers]() Original publisher: [Read original article]() Published: 2026-01-14T02:34:22Z Content type: article Language: en Sources: [Tony Finch's blog]() Topics: [HTTP](), [Algorithms](), [Internet Engineering Task Force (IETF)](), [client]() Tags: [algorithm](), [client](), [headers](), [http](), [ietf](), [server]() ### AI overview The article examines the IETF draft for HTTP RateLimit headers and argues that the headers can support linear rate-limit algorithms such as GCRA, encouraging smoother client request behavior than quota-reset algorithms. ### Source excerpt There is an IETF draft that aims to standardize RateLimit header fields for HTTP. A RateLimit header in a successful response can inform a client when it might expect to be throttled, so it can avoid 429 Too Many Requests errors. Servers can also include RateLimit headers in a 429 response to make the error more informative. The draft is in reasonably good shape. However as written it seems to require (or at least it assumes) that the server uses bad quota-reset rate limit algorithms. Quota-reset algorithms encourage clients into cyclic burst-pause behaviour; the draft has several paragraphs discussing this problem. However, if we consider that RateLimit headers are supposed to tell the client what acceptable behaviour looks like, they can be used with any rate limit algorithm. (And it isn't too hard to rephrase the draft so that it is written in terms of client behaviour instead of server behaviour.) When a client has more work to do than will fit in a single window's quota, linear rate limit algorithms such as GCRA encourage the client to smooth out its requests nicely. In this article I'll describe how a server can use a linear rate limit algorithm with HTTP RateLimit headers. spec summary policy parameters linear rate limit algorithm other rate limiters spec summary The draft specifies two headers: RateLimit-Policy: describes input parameters to a rate limit algorithm, which the server chooses based on the request in some unspecified way. The policies are expected to be largely static for a particular client. The parameters are, the name of the policy pk, the partition key q, the quota w, the window qu, the quota units RateLimit: describes which policies the server applied to this request, and the output results of the rate limit algorithm. The results are likely to vary per request depending on client behaviour or server load, etc. The results are, the name of the policy pk, the partition key r, the available quota t, the effective window Both headers can list ## IETF v6ops Working Group with Nick Buraglio DevFeed: [IETF v6ops Working Group with Nick Buraglio]() Original publisher: [Read original article]() Published: 2025-12-11T07:03:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Internet Engineering Task Force (IETF)](), [Networks](), [Deployment]() Tags: [ietf](), [ipv6](), [networks](), [podcast](), [software-gone-wild]() ### AI overview This article discusses why the IETF v6ops Working Group remains active 30 years after the first IPv6 specifications. It highlights the group's work on guidelines for deploying and operating IPv6 networks and references Nick Buraglio's answers in Episode 203 of the Software Gone Wild podcast. ### Source excerpt The first IPv6 specs were published in 1995, and yet 30 years later, we still have a pretty active IETF working group focused on "developing guidelines for the deployment and operation of new and existing IPv6 networks." (taken from the old charter; they updated it in late October 2025). Why is it taking so long, and what problems are they trying to solve? Nick Buraglio, one of the working group chairs, provided some answers in Episode 203 of the Software Gone Wild podcast. Read more ... ## IS-IS 3-Way Handshake and the Power of SHOULD DevFeed: [IS-IS 3-Way Handshake and the Power of SHOULD]() Original publisher: [Read original article]() Published: 2025-07-01T06:17:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [IS-IS](), [Cisco](), [Internet Engineering Task Force (IETF)](), [Handshake]() Tags: [cisco](), [download](), [ietf](), [is-is](), [standard](), [standards]() ### AI overview The article explains why Cisco's pre-standard IS-IS 3-way handshake can interoperate with RFC 5303 implementations. It attributes this to RFC 5303 making some TLV 240 fields optional, while Cisco's IETF handshake includes additional fields that can be validated when present. ### Source excerpt Yesterday, I mentioned that a Cisco router running pre-standard IS-IS 3-way handshake (this is why you need it) interoperates with multiple implementations of RFC 5303. How's that possible, and does it matter whether you configure the ancient Cisco routers (release 15.x) to use IETF 3-way handshake instead of the "proprietary" one? TL&DR: It SHOULD NOT matter, but the more I explore the RFCs, the more I'm amazed anything works at all. I took a trip to the Wireshark land to figure out the details (you can download the capture file): Read more ... ## New IPv6 Documentation Prefix DevFeed: [New IPv6 Documentation Prefix]() Original publisher: [Read original article]() Published: 2025-01-11T06:51:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Internet Engineering Task Force (IETF)](), [Documentation]() Tags: [documentation](), [ietf](), [ipv6]() ### AI overview The article discusses RFC 9637, which defines the larger 3fff::/20 IPv6 documentation prefix after discussions in the IETF v6ops working group. It argues that examples should use documentation address space instead of public IPv6 addresses. ### Source excerpt After three and a half years of haggling (the IETF draft that became the RFC was written in May 2021; the original discussions go back to 2013), Nick Buraglio & co managed to persuade pontificators bikeshedding in the v6ops working group that we might need an IPv6 documentation prefix larger than the existing 2001:db8::/32. With the new documentation prefix (3fff::/20) (defined in RFC 9637), there's absolutely no excuse to use public IPv6 address space in examples anymore. ## WTF Are JWTs? DevFeed: [WTF Are JWTs?]() Original publisher: [Read original article]() Author: Andrew Tate Published: 2024-11-29T16:37:34Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [JSON Web Tokens](), [Authentication](), [Authorization](), [Security](), [Internet Engineering Task Force (IETF)](), [Scalability]() Tags: [authentication](), [authorization](), [community](), [ietf](), [scalability](), [security](), [tokens](), [web]() ### AI overview This article explains what JSON Web Tokens (JWTs) are, how digitally signed JSON objects enable parties to verify transmitted information, and why JWTs became widely used for stateless authentication. It also connects JWTs to Neon RLS and Postgres authorization, and describes their benefits for cross-domain compatibility, scalability, flexibility, and security. ### Source excerpt We recently launched Neon RLS to simplify Postgres authorization with row-level security. If you've been reading our posts, tutorials, or READMEs on the subject, you'll have come across three little letters: JWT. This whole world seems to run on JWTs-so what are they? JWTs, or JS... ## IPv6 Support for Multiple Routers and Multiple Interfaces DevFeed: [IPv6 Support for Multiple Routers and Multiple Interfaces]() Original publisher: [Read original article]() Published: 2024-11-28T10:57:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [Internet Engineering Task Force (IETF)](), [Networks](), [Internet](), [Protocol (disambiguation)](), [Mobile]() Tags: [ietf](), [internet](), [ipv6](), [mobile](), [nat](), [networks](), [protocol](), [tcp]() ### AI overview The article comments on Fernando Gont's Individual Internet Draft about IPv6 support for multiple routers and interfaces. It argues that the draft clearly describes a long-standing multihoming problem and says current practical options are NAT or rarely implemented host-based solutions, while questioning whether an IETF working group will adopt the draft. ### Source excerpt Fernando Gont published an Individual Internet Draft (meaning it hasn't been adopted by any IETF WG yet) describing the Problem Statement about IPv6 Support for Multiple Routers and Multiple Interfaces. It's so nice to see someone finally acknowledging the full scope of the problem and describing it succinctly. However, I cannot help but point out that: I was ranting about that problem in 2009 (15 years ago) and did a summary of older rants in 2015. It was evident to everyone but the religious zealots that the only solution we have at the moment is either NAT (because stuff simply does not work otherwise) or host-based solutions that never got implemented (apart from a few rare cases of multipath TCP). Anyway, Fernando wraps up his draft with: Read more ... ## 22 years later, YAML now has a media type DevFeed: [22 years later, YAML now has a media type]() Original publisher: [Read original article]() Author: HTTP Toolkit; Tim Perry Published: 2024-02-20T15:00:00Z Content type: article Language: en Sources: [HTTP Toolkit]() Topics: [YAML](), [HTTP](), [API](), [interoperability](), [OpenAPI Specification](), [Internet Engineering Task Force (IETF)](), [Security](), [Rails]() Tags: [api](), [http](), [ietf](), [interoperability](), [openapi](), [security](), [specifications](), [standard](), [standards](), [yaml]() ### AI overview The article explains that RFC 9512 formally registers application/yaml as the media type for YAML and defines +yaml as a structured suffix for YAML-based media types. It discusses the implications for HTTP metadata, OpenAPI specifications, interoperability, existing application conventions, and security considerations. ### Source excerpt As of February 14th 2024, RFC 9512 formally registers application/yaml as the media type for all YAML content, and adds +yaml as a standard structured suffix for all YAML-based more specific media types. With this registration, it's now included in the official media types list maintained by the IANA. Media types like this (also known as the MIME types, from their original invention for email attachment metadata) are heavily used particularly in HTTP Content-Type headers for both requests & responses, and in all sorts of file metadata and processing logic elsewhere. These names give applications a common vocabulary to describe data when passing it around. The additional +yaml suffix also defined here is particularly useful. Media type structured suffixes like this (+xml and +json are other common examples) are used to define specific types for content that's based on an existing generic content type (such as YAML). In this case, this notably opens the door to standardization of other YAML-based MIME types, such as application/openapi+yaml (for OpenAPI specifications that are written in YAML) which is currently being formalized in another standard, following closely behind this one. While a few applications have been using application/yaml and +yaml like this already, many haven't (e.g. Rails still uses application/x-yaml, and others like text/yaml and even text/x-yaml are frequently seen in the wild) and there's never been clear agreement on exactly how this should work. Hopefully with this RFC we'll be able to start picking a single media type consistently from now on, though updating older applications here will obviously take some time. The full RFC is well worth a read if you're interested in the finer details, and discusses all sorts of more detailed questions around interoperability for an evolving language like YAML, its relationship with JSON, and the (many) security considerations to be aware of when defining a formal API around YAML data. This RFC is just ## Working with the new Idempotency Keys RFC DevFeed: [Working with the new Idempotency Keys RFC]() Original publisher: [Read original article]() Author: HTTP Toolkit; Phil Sturgeon Published: 2023-12-12T15:00:00Z Content type: tutorial Language: en Sources: [HTTP Toolkit]() Topics: [HTTP](), [Internet Engineering Task Force (IETF)](), [client](), [Server](), [stripe]() Tags: [apis](), [http](), [ietf](), [payment](), [request](), [server](), [standards](), [stripe](), [timeout]() ### AI overview This article explains how idempotency keys make retries safe for HTTP API operations, especially POST and PATCH requests that modify server state. It discusses an IETF draft RFC and the risks of duplicate actions such as payments when clients time out. ### Source excerpt Idempotency is when doing an operation multiple times is guaranteed to have the same effect as doing it just once. When working with APIs this is exceptionally helpful on slow or unreliable internet connections, or when dealing with particularly sensitive actions such as payments, because it makes retrying operations safe and reliable. This is why most payment gateways like Stripe and Adyen support 'idempotency keys' as a key feature of their APIs. Recently, the IETF have gone further, and created a draft RFC standard for this useful common pattern, as part of the 'Building Blocks for HTTP APIs' working group. This is technically still a draft and the details could change, but it's fairly mature now and increasingly widely used, so it's a good time to take a closer look, and start using & implementing it for yourself. Idempotency in HTTP APIs Many HTTP methods are defined as idempotent in all cases. In theory, any GET, HEAD, PUT, DELETE, OPTIONS, or TRACE operation can be executed multiple times without any unintended side effects (though for badly behaved APIs your mileage may vary). The idea is that an HTTP request like DELETE /users/123 clearly wants to delete that user, and if that accidentally happens twice then that's just fine. User 123 ends up deleted just the same. It's a lot more complicated for POST and PATCH requests, which do not provide that same level of confidence out of the box. These are designed to allow non-idempotent operations, like adding a new user, sending a payment, or appending to existing data. Those are important use cases too - sometimes you really do want to send the same thing twice, and have it happen twice - but this can cause problems when things go wrong. When sending POST and PATCH requests to modify server state, if you want to support retries then both the client and server need to explicitly handle this - which is exactly what idempotency keys are designed to allow you to do. How can non-idempotency go wrong? Without idempoten ## New HTTP standards for caching on the modern web DevFeed: [New HTTP standards for caching on the modern web]() Original publisher: [Read original article]() Author: HTTP Toolkit; Tim Perry Published: 2021-10-20T14:00:00Z Content type: article Language: en Sources: [HTTP Toolkit]() Topics: [HTTP](), [Caching](), [Internet Engineering Task Force (IETF)](), [Web](), [Back end](), [servers]() Tags: [backend](), [cache](), [cache-control](), [caching](), [cdn](), [http](), [ietf](), [latency](), [performance](), [server](), [standards](), [web]() ### AI overview This article explains two emerging IETF HTTP standards for CDN and cache management: the Cache-Status header and Targeted Cache-Control Headers. It describes how they are intended to improve cache debugging and configuration, while noting that both specifications are still new and widespread support is not yet expected. ### Source excerpt If you run any large public-facing website or web application on the modern web, caching your static content in a CDN or other caching service is super important. It's also remarkably complicated and confusing. Fortunately, the HTTP working group at the Internet Engineering Task Force (IETF) is working to define new HTTP standards to make this better. There's been a lot of work here recently to launch two new HTTP header draft standards intended to make debugging your caching easier, and to provide more control over your cache configuration. Let's see what that means, how these work, and why everyone developing on the web should care. The Standards The two proposed standards I'm talking about are: The Cache-Status Header Targeted Cache-Control Headers These are designed to update HTTP standards to match the reality of the CDN-powered web that exists today, creating specifications that formalize existing practices from popular CDNs (like Fastly, Akamai & Cloudflare, all of whom have been involved in the writing the standards themselves). Both of these are fairly new specifications: Cache-Status has completed multiple rounds of review in 2021 and is currently awaiting (since August) final review & publication as a formal RFC, while Targeted Cache-Control Headers is currently an adopted draft standard, but in its last call for feedback. In both cases, they're backed by the IETF, they're received a lot of discussion already and it's unlikely they'll change much beyond this point, but they're also still new, so support isn't likely to be widespread yet. Why does caching matter? If you're running a high-profile user-facing web application, caches and CDNs are absolutely critical to providing good performance for end users at a reasonable cost. Caches and CDNs sit in front of your web server, acting as a reverse proxy to ensure that: Content is cached, so your backend server only receives occasional requests for static content, not one request direct from every visitor. Co ## Defining a new HTTP method: HTTP QUERY DevFeed: [Defining a new HTTP method: HTTP QUERY]() Original publisher: [Read original article]() Author: HTTP Toolkit; Tim Perry Published: 2021-04-12T15:00:00Z Content type: article Language: en Sources: [HTTP Toolkit]() Topics: [HTTP](), [API](), [Internet Engineering Task Force (IETF)]() Tags: [api](), [apis](), [draft](), [http](), [ietf](), [request](), [responses](), [server](), [standards]() ### AI overview This article introduces HTTP QUERY, a new HTTP method for safe requests that include a request body. It explains why the method is needed and compares it with existing HTTP methods such as GET and POST. The article notes that HTTP QUERY was recently adopted as an IETF draft standard and that its specification evolved from the earlier name SEARCH. ### Source excerpt Nothing is ever finished or perfect, and HTTP is no exception. HTTP QUERY is a new HTTP method, for safe requests that include a request body. It's still early & evolving, but it was recently adopted as an IETF draft standard, and it's going to add some great new tools for HTTP development everywhere. What does that mean, why do we need a new HTTP method, how would HTTP QUERY work? Update: This post previously called this method SEARCH, but since it was originally published the spec has been updated, and the method is now called QUERY. This post has been updated accordingly. HTTP methods today Today, there are 5 main HTTP methods you'll see in modern APIs. To understand how each one works, it's important to remember that HTTP is defined in terms of resources. A resource might be a document, or a photo, or a specific customer, or the whole list of customers, and it's identified by a URL like example.com/customers (all customers of example.com) or example.com/customers/123 (one specific customer). GET A GET request asks the server for a resource. This is frequently used to request HTML pages, read data from an API, or load images. These are intended to be 'safe' requests, which purely read data. They shouldn't change the state of the server, they shouldn't have side effects, and so they can be cached in many cases (which means that many client GET responses will come from a cache, and never hit the real server). GET requests can be parameterized by their URL, which might contain a path and/or query parameters, but they can't have a request body. It's not specifically banned, but it is defined as being completely meaningless, and many existing implementations will ignore the body or reject the request entirely if you try to send one. They can also use Accept, Accept-Language and Accept-Encoding headers to request a specific content type, language or encoding ('give me customer 123 as XML please'), and use Range headers to request only part of a document ('give me the f ## The right way to turn off your old APIs DevFeed: [The right way to turn off your old APIs]() Original publisher: [Read original article]() Author: HTTP Toolkit; Tim Perry Published: 2021-01-21T10:30:00Z Content type: tutorial Language: en Sources: [HTTP Toolkit]() Topics: [API](), [HTTP](), [Internet Engineering Task Force (IETF)](), [Logging](), [stripe]() Tags: [api-metrics](), [apis](), [http](), [ietf](), [logging](), [standards](), [stripe]() ### AI overview This tutorial explains how to safely shut down old HTTP APIs. It recommends checking usage through metrics or logging, considering internal translation to newer APIs, and creating a deprecation plan when continued support is impractical. It also discusses two draft headers from the IETF Building Blocks for HTTP APIs working group. ### Source excerpt All things come to an end, even HTTP APIs. However great your API may be today, one day you'll want to release a completely new version, an improved but incompatible endpoint, a new parameter that solves the same problem better, or to shut down your API entirely. Your current API will not be live forever. Inconveniently though, your API has clients. If you shut down endpoints, parameters, or entire APIs without properly warning them then they're going to be very unhappy. How do you shut down your APIs safely, making it at easy as possible for your users? There are right ways to do this, including two new draft headers being standardized by the exciting new IETF "Building Blocks for HTTP APIs" working group, designed to help with this exact process. Let's take a look. Make a plan First up: check if the API in question actually has any clients. Hopefully you have some API metrics or at least logging somewhere. If you don't, add some! If you do, and you can tell for sure that nobody is using this API anymore, then you win. Turn it off right now, delete the code, skip this article and have a well-deserved nap. The next question, if you're not napping, is to ask yourself whether there's an alternative to shutting down this API. Everything you turn off will break somebody's code and take their time to fix it. It's good for the health of your client ecosystem and the web as a whole if APIs keep working. In many cases, old APIs can be translated internally, to transparently transform requests into calls to a new API instead, without maintaining two completely independent versions. This is a fundamental part of the API versioning approach at Stripe who include transformations with all API changes to ensure that requests for incompatible old versions continue to work as before, automatically translating the requests and responses to use the newer code as required. Translation like this isn't always possible, and doing so forever can entail significant extra complexity, but if ## RFC 7807 standardizes HTTP API error response details DevFeed: [RFC 7807 standardizes HTTP API error response details]() Original publisher: [Read original article]() Author: HTTP Toolkit; Tim Perry Published: 2020-11-24T13:35:00Z Content type: tutorial Language: en Sources: [HTTP Toolkit]() Topics: [API](), [HTTP](), [Internet Engineering Task Force (IETF)](), [client]() Tags: [api](), [apis](), [error-handling](), [errors](), [http](), [ietf](), [responses](), [standard](), [standards]() ### AI overview The article explains that HTTP status codes often do not provide enough detail to diagnose API failures. It presents RFC 7807 from the IETF as a proposed standard format for HTTP API error responses, with consistent error identifiers, descriptions, and metadata. ### Source excerpt When an API request doesn't work, hopefully the client receives a sensible HTTP error status, like 409 or 500, which is a good start. Unfortunately though, whilst 400 Bad Request might be enough to know who's at fault, it's rarely enough information to understand or fix the actual problem. Many APIs will give you more details in the response body, but sadly each with their own custom style, varying between APIs or even between individual endpoints, requiring custom logic or human intervention to understand. This is not inevitable. Suspend disbelief with me for a second. Imagine a better world, where instead every API returns errors in the same standard format. We could have consistent identifiers to recognize types of errors, and clear descriptions and metadata easily available, everywhere. Your generic HTTP client could provide fine-grained details for any error automatically, your client error handling could easily & reliably differentiate specific errors you care about, and you could handle common errors across many different APIs with one set of shared logic. RFC 7807 from the IETF is a proposed standard aiming to do exactly this, by defining a standard format for HTTP API error responses. It's seeing real-world usage already, it's easy to start supporting in existing APIs and clients, and it's well worth a look for everybody who builds or consumes HTTP APIs. Why is a standard error format useful? (Please don't do this) Let's step back a little. One key feature of HTTP is the use of standard response status codes, like 200 or 404. When used correctly, these ensure that clients can automatically understand the overall status of a response, and take appropriate action based on that. Status codes are especially great for error handling. Rather than requiring custom rules to parse & interpret every response everywhere, almost all standard HTTP clients will throw an error automatically for you when a request receives an unexpected 500 status, and this ensures that un ## eth2 quick update no. 7 DevFeed: [eth2 quick update no. 7]() Original publisher: [Read original article]() Author: Danny Ryan Published: 2020-01-16T00:00:00Z Content type: news Language: en Sources: [Ethereum Foundation Blog]() Topics: [releases](), [Security](), [Internet Engineering Task Force (IETF)](), [Development]() Tags: [attacks](), [audits](), [ietf](), [news](), [python](), [release](), [research-development](), [security](), [update]() ### AI overview This update reports the release of the v0.10.0 eth2 specification as a stable target for multi-client testnets and security reviews. It also covers client development, the relaunch of the Prysm testnet, IETF BLS integration, security audits, and research into Phase 0 cryptoeconomics and attacks. ### Source excerpt Welcome to the first eth2 quick update of 2020! This is going to be an exciting year. tldr; Release of v0.10.0 spec as stable target for multi-client testnets and security reviews @paulhauner and @sigp_io team hard at work building Lighthouse Relaunch of [... ## eth2 quick update DevFeed: [eth2 quick update]() Original publisher: [Read original article]() Author: Danny Ryan Published: 2019-10-23T00:00:00Z Content type: news Language: en Sources: [Ethereum Foundation Blog]() Topics: [Blockchain](), [Internet Engineering Task Force (IETF)](), [Development](), [Testing]() Tags: [blockchain](), [community](), [development](), [ietf](), [research-development](), [standard](), [testing](), [update]() ### AI overview This update reports progress on eth2, including a completed and verified deposit contract, ongoing BLS signature standardization, changes to the Phase 0 sharding design, and preparations for multi-client public testnets. ### Source excerpt Although the internet has been more quiet than usual, we've been super busy hacking away on eth2! Between Devcon5 and keeping our heads down to work, it seems we've left the community in the dark on a couple of items. Here's a quick update to fill in the gaps....