FastAPI 0.156.3 has been released as a focused patch that fixes a bug in how AliasChoices behaves for query parameters, headers, and cookies. The change comes from PR #16555, authored by @tiangolo, and addresses scenarios where multiple accepted parameter names did not resolve correctly across those three input sources. It is a small, single-purpose release rather than a feature drop, which is typical of the project's patch cadence.
AliasChoices lets a developer declare several alternative names for a single parameter, which matters when an API must accept legacy names alongside new ones. The bug meant that behavior was unreliable outside the body, specifically for query strings, request headers, and cookies. The 0.156.3 patch resolves that inconsistency.
- Fixed
AliasChoicesresolution for query parameters, so alternative names provided in the query string are matched as intended. - Fixed
AliasChoicesresolution for headers, ensuring multiple accepted header names map to the declared parameter. - Fixed
AliasChoicesresolution for cookies, so alternative cookie names are honored. - Delivered as PR #16555 by @tiangolo, with no other changes listed in this release.
The practical implication is straightforward: if you maintain endpoints that accept renamed or backward-compatible inputs via AliasChoices, upgrading to 0.156.3 should let you drop workaround code that manually inspected Request objects or duplicated parameters. Header-based variants are especially common in APIs that negotiate content types or carry API keys under more than one name, and cookie aliases appear in session and auth flows. Because this is a patch release, the upgrade risk is low, but it is still worth exercising your alias-dependent endpoints in tests after bumping the pin. Pinning to [email protected] gives you the corrected behavior without pulling in unrelated changes.
Source: https://github.com/fastapi/fastapi/releases/tag/0.156.3