curl 8.22 Keeps Parsing Alt-Svc After Unknown Parameters

curl 8.22.0, released September 2, 2026, changes how libcurl parses parameters in an Alt-Svc response header. The curl project describes the bugfix as “altsvc: continue after unknown parameters.” The underlying change explains that an unfamiliar extension value could make the older parser stop before a later valid ma or persist parameter was processed.

The problem was not that curl accepted an arbitrary extension as a known setting. Instead, the parser attempted to interpret every parameter value as a number. A nonnumeric token or quoted-string belonging to an unknown extension could end parsing early. That could leave a later maximum-age or persistence directive unseen even though unknown Alt-Svc parameters are meant to be ignored.

curl 8.22 parses the extension name and its token or quoted-string value, decides whether the parameter is known, and continues. Numeric validation still applies to the recognized ma and persist settings.

Why this matters to proxy-backed clients

Alt-Svc lets an HTTPS origin advertise an alternative service, often another protocol or endpoint. A libcurl application can keep that information in memory or in an Alt-Svc cache file and consider it when creating a later connection.

Proxy-backed data collection, regional availability checks and ad-verification systems can have several connection layers: client to proxy, optional CONNECT tunnel, proxy exit to origin, and an alternative origin service. A stale or partially parsed cache entry can change protocol selection, expiration behavior and the route used for a new connection. That makes a parser detail operationally relevant even though it does not alter proxy credentials or pool selection directly.

Do not interpret this release note as a universal HTTP/3 or proxy fix. It specifically affects Alt-Svc parameter parsing when an unknown parameter appears before recognized values that the application relies on.

The affected header shape

Prioritize regression testing when all of these conditions apply:

• the application enables libcurl's Alt-Svc engine;
• a trusted HTTPS origin returns an Alt-Svc header;
• an alternative entry contains an extension parameter unknown to curl;
• a valid ma or persist parameter appears after that extension;
• later requests depend on the cache entry's expiry or persistence behavior.

A simple header with only known parameters may not expose the difference. The useful regression places an unknown token value or quoted-string value before the recognized fields.

Security boundaries remain in place

According to libcurl's Alt-Svc controls, Alt-Svc headers are accepted only over HTTPS, and an alternative origin is used only over HTTPS. Alternative services are considered when setting up new connections; if a suitable existing connection is already in the pool, it is preferred.

Those rules matter when validating the fix. A test that reuses the same live HTTP/2 connection may never exercise the Alt-Svc decision. Likewise, a plain HTTP response should not be treated as a valid production control for an HTTPS-only feature.

Use the TLS session resumption test to separate a new alternative-service connection from connection reuse and resumed TLS. For HTTP/3-specific response handling, see the curl 8.22 HTTP/3 proxy header update.

Build a controlled regression

Use a test origin and proxy accounts that your organization owns or is authorized to assess. Configure three Alt-Svc response variants:

1. a baseline entry with known ma and persist parameters only;
2. an unknown token-valued parameter followed by valid ma and persist;
3. an unknown quoted-string parameter containing spaces, an escaped quote or a semicolon, followed by the same valid fields.

Keep the advertised protocol, alternative host, port and response content constant. Use a low request rate and a short test maximum age so the cache lifecycle can be observed safely.

Verify parsing, not just request success

A request can succeed through the original origin while the Alt-Svc cache is wrong. Capture:

• the curl and libcurl runtime version;
• enabled Alt-Svc protocol flags;
• source origin, advertised protocol, alternative host and port;
• the complete test header before redaction;
• whether the unknown value used token or quoted-string syntax;
• parsed maximum age and persistence state;
• cache creation and update time;
• whether the next request reused an existing connection or opened a new one;
• negotiated protocol, selected peer and validated response outcome.

Never place live proxy credentials, cookies or authorization headers in the fixture or logs.

Test expiry behavior

The ma value controls how long the alternative service can remain valid. Create a short controlled maximum age, observe the entry before expiry, then test again after expiry. The client should not keep routing new connections through an expired entry.

If an unknown extension previously hid a later ma, the observed cache lifetime may differ across versions. Compare actual stored expiry rather than relying only on whether a single request used the alternative.

Test persistence separately

Persistence determines whether an Alt-Svc entry is intended to survive certain network changes. Do not combine this with cache-file persistence or process restart behavior as though they were identical.

Run one test in memory, one with a dedicated non-privileged cache file, and one after an intentional process restart if your application stores the cache. Restrict file permissions and keep the cache in a directory that untrusted users cannot modify. An attacker who can replace the cache file may influence connection routing.

Include proxy-path controls

Run the same header variants:

• directly to the controlled origin;
• through one stable authorized HTTP CONNECT route;
• through a controlled rotating route while preserving the same origin response;
• with connection reuse disabled for the measured follow-up request;
• with Alt-Svc disabled as a negative control.

The parser result should be consistent across network paths because the header belongs to the trusted origin response. Differences may indicate that a gateway modifies headers, the client uses a different runtime build, or a live connection prevents the new-connection decision from running.

Roll out curl 8.22 safely

Inventory the actual libcurl loaded by containers, language bindings and long-running workers. Upgrade one cohort, clear only the test cache, and compare it with an unchanged control. Preserve enough evidence to distinguish cache parsing from DNS, TLS, proxy authentication, exit health and HTTP/3 negotiation.

Stop rollout if the alternative destination is incorrect, expired entries remain active, trust validation changes, or response validation fails. The expected change is narrower: unknown extension values no longer prevent later recognized parameters from being parsed.

Verification checklist

• [ ] The runtime is curl/libcurl 8.22.0 or later.
• [ ] The Alt-Svc engine is explicitly enabled for the intended protocols.
• [ ] Test headers arrive from a controlled HTTPS origin.
• [ ] Unknown token and quoted-string values precede valid known parameters.
• [ ] Parsed maximum age and persistence match the fixture.
• [ ] Expired entries are not selected for new connections.
• [ ] Live connection reuse is separated from Alt-Svc selection.
• [ ] Direct and authorized proxy paths produce equivalent parser results.
• [ ] Cache files have restricted ownership and permissions.
• [ ] Every success includes protocol, peer and response-content validation.

FAQ

Does curl 8.22 start trusting unknown Alt-Svc extensions?

No. The fix lets the parser consume and ignore unknown extension values so it can continue to later recognized parameters. Unknown fields do not become supported settings.

Does Alt-Svc replace my proxy configuration?

No. It is origin-provided alternative-service metadata. Proxy selection, tunneling and exit policy remain separate application decisions, though the complete connection path should be tested together.

Why did my follow-up request stay on HTTP/2?

A suitable live connection may be reused before a new Alt-Svc connection is considered. The advertised protocol may also be unsupported or disabled in the runtime. Confirm build features and force a controlled new-connection test.

Should production jobs share one Alt-Svc cache file?

Only if ownership, permissions, origin boundaries and concurrent access have been designed and reviewed. A per-application or per-trust-domain cache is safer than an unrestricted shared file.

Source and compliance note

Internal research used the curl 8.22.0 change log dated September 2, 2026, curl pull request 22644 opened August 23, 2026, and the current libcurl Alt-Svc option documentation. Public article text intentionally contains no external URLs.

Test only origins, proxy accounts and networks you own or are authorized to use. Respect platform terms, rate limits, privacy obligations and regional law. Alt-Svc testing must not be used to bypass access controls or disguise prohibited automation.