Kubo 0.43.1: What Shipped and What to Test

The release is about gateway correctness

The 0.43.1 release record is explicit that it is a maintenance pass. The headline change is the `ipfs-uri` response header on path-gateway redirects. The IPFS HTTP gateway specification describes this header as the mechanism a path-gateway uses to tell a client the actual content identifier behind a redirected path, so the header is a spec alignment, not an invention of this release.

The reason it matters is that subdomain and path gateways frequently serve content under a URL that is not the CID the content resolves to. Before this, a redirect had to carry the full destination in the location; now the header can carry the content identity as a first-class field. If you run a public or semi-public gateway, confirm your reverse proxy forwards the header and that your clients do not silently drop it.

HTTP/3 and QUIC come from the boxo dependency

The release notes for 0.43.1 reference boxo 0.42.2 as the pinned dependency. boxo 0.42.2 is where the HTTP/3 and QUIC-related work landed for this line, including the draft-http3 stack and connection handling. In practical terms, upgrading Kubo 0.43.1 means your gateway's HTTP/3 path is now the one shipped by boxo 0.42.2, and any tuning you did against an earlier boxo should be re-checked.

If you run behind a proxy that terminates HTTP/3 at the edge, the change is largely transparent. If you terminate it inside Kubo, re-verify your listener configuration and your client's ability to fall back to HTTP/2 or TCP, because a misconfigured QUIC path can look like intermittent connection failures rather than an obvious config error.

Provider announcements and DHT reliability

The release record also carries reliability work around provider announcements and DHT lookups. This is the part that is easy to overlook in a maintenance release but is the part that decides whether content you publish is actually findable by other nodes. If your nodes were intermittently failing to provide for content they pinned, a 0.43.1 upgrade is a reasonable place to test whether the announcement path is now stable.

The honest framing: the release notes state these are fixes, not a guarantee that every network condition is handled. Provider behavior still depends on your node's connectivity, its DHT participation settings, and whether it is announced correctly. Treat the upgrade as a candidate fix to verify, not a resolution to assume.

Upgrade order and what to re-verify

Because 0.43.1 moves the boxo stack, the safe upgrade sequence is: pin the exact 0.43.1 artifact and the boxo 0.42.2 version, back up your repository config and datastore, then run the node against a test set of content covering (a) a direct CID fetch, (b) a path-gateway redirect, and (c) a provider lookup for content you publish. Record the before/after behavior for each before touching production.

What the release does not prove

The release record describes what shipped; it does not measure your network. It does not tell you whether your reverse proxy forwards the new header, whether your DHT participation is healthy, or whether your storage backend can handle the announcement load. Those are all environment-specific and have to be tested in your environment. The release is a correctness update: your job is to confirm the correctness holds under your specific configuration.

Reading the release record itself

The 0.43.1 release record is short, and reading it carefully is part of the upgrade. It names the boxo dependency it pins, it lists the header behavior on path-gateway redirects, and it carries the provider and DHT reliability fixes. It does not, on its own, enumerate every behavioral change, because a meaningful share of the change lives in the boxo dependency rather than in Kubo's own commits. That is the trap with a maintenance release in a library-driven codebase: the patch notes describe the top layer, and the substantive behavior is one layer down, in the library pin.

The practical habit it builds is to read the dependency release too, not just the top-level tag. When you see Kubo pin a new boxo version, open the boxo release for that version and read what changed in the gateway, routing, and block layers, because that is where the observable behavior will come from. The Kubo tag tells you what to test; the boxo tag tells you why the test will show what it shows. Doing both is the difference between a confident upgrade and one you can only describe as 'probably fine.'

Limitations

• A release note is not a deployment audit. It does not inspect your operating system, network policy, credentials, storage, backups, or administrative process.
• Version numbers and documentation change. Pin the exact artifacts you test, record the date, and re-check upstream material before a production change.
• A feature that exists in a package or command does not automatically fit your threat model. Authentication, authorization, logging, patching, recovery, and abuse controls remain operator responsibilities.
• This article contains no benchmark, uptime promise, adoption statistic, cost saving, or client result. Measure those claims in your environment; the release record can only describe what shipped.

Related infrastructure context

For the physical layer around a systems deployment, TismTek provides fiber and network infrastructure work near Aurora. The team also documents on-premises compute and private AI systems. For a site discussion, call (720) 694-1976. See the IPFS/Kubo content addressing and provider records for recovery planning and the private AI systems overview for the broader on-premises context.