chore(deps): Update httpx requirement from <1.0,>=0.27 to >=0.28.1,<1.0

[dependabot]

Updates the requirements on httpx to permit the latest version.

Release notes

Sourced from httpx's releases.

Version 0.28.1

0.28.1 (6th December, 2024)

• Fix SSL case where verify=False together with client side certificates.

Changelog

Sourced from httpx's changelog.

0.28.1 (6th December, 2024)

• Fix SSL case where verify=False together with client side certificates.

0.28.0 (28th November, 2024)

Be aware that the default JSON request bodies now use a more compact representation. This is generally considered a prefered style, tho may require updates to test suites.

The 0.28 release includes a limited set of deprecations...

Deprecations:

We are working towards a simplified SSL configuration API.

For users of the standard verify=True or verify=False cases, or verify=<ssl_context> case this should require no changes. The following cases have been deprecated...

• The verify argument as a string argument is now deprecated and will raise warnings.
• The cert argument is now deprecated and will raise warnings.

Our revised SSL documentation covers how to implement the same behaviour with a more constrained API.

The following changes are also included:

• The deprecated proxies argument has now been removed.
• The deprecated app argument has now been removed.
• JSON request bodies use a compact representation. (#3363)
• Review URL percent escape sets, based on WHATWG spec. (#3371, #3373)
• Ensure certifi and httpcore are only imported if required. (#3377)
• Treat socks5h as a valid proxy scheme. (#3178)
• Cleanup Request() method signature in line with client.request() and httpx.request(). (#3378)
• Bugfix: When passing params={}, always strictly update rather than merge with an existing querystring. (#3364)

0.27.2 (27th August, 2024)

Fixed

• Reintroduced supposedly-private URLTypes shortcut. (#2673)

0.27.1 (27th August, 2024)

Added

• Support for zstd content decoding using the python zstandard package is added. Installable using httpx[zstd]. (#3139)

Fixed

• Improved error messaging for InvalidURL exceptions. (#3250)
• Fix app type signature in ASGITransport. (#3109)

0.27.0 (21st February, 2024)

... (truncated)

Commits

• 26d48e0 Version 0.28.1 (#3445)
• 89599a9 Fix verify=False, cert=... case. (#3442)
• 8ecb86f Add test for request params behavior changes (#3364) (#3440)
• 0cb7e5a Bump the python-packages group with 11 updates (#3434)
• 15e21e9 Updating deprecated docstring Client() class (#3426)
• 80960fa Version 0.28.0. (#3419)
• a33c878 Fix extensions type annotation. (#3380)
• ce7e14d Error on verify as str. (#3418)
• 47f4a96 Handle empty zstd responses (#3412)
• 189fc4b Update CHANGELOG.md, fix typo(s) (#3406)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[github-actions]

Aragora Code Review

Advisory-only review. Findings are surfaced for follow-up and do not fail this workflow.

Round 2: Skeptical Review — Challenging My Own HIGH Finding

The Round 2 critic (severity 10.0) pushed two things: (1) add a CI guard against removed-API patterns, and (2) upgrade the tri-location duplication to MEDIUM. Before I accept either, the skeptic's job is to ask whether my own Round 1 HIGH finding was over-stated. Let me challenge the strongest claim in my own proposal first, because that's where the largest unexamined assumption sits.

Self-Challenge #1: Is the "HIGH / runtime TypeError" finding actually justified by this diff?

My Round 1 proposal escalated the proxies/app removal to HIGH and called it "the single most important thing a reviewer should verify." On skeptical re-examination, that severity rests on an unverified premise: that first-party code in this repo actually passes proxies= or app= to an httpx client. I never established that. I asserted a risk and assigned it HIGH severity based on the possibility of usage, not evidence of it.

This is a real logical flaw, and it cuts against me:

• The floor was >=0.27, not <0.28. The previous constraint already allowed installing httpx 0.28.x.
  The httpx package is not yet at a 1.0 SEMVER release
  , and a constraint of >=0.27,<1.0 means any resolver — including the existing uv.lock — could already have resolved to 0.28.0 or 0.28.1 before this PR. If the repo's code used proxies=, it would already be broken under the old constraint whenever the lockfile resolved to ≥0.28. So either (a) the code doesn't use the removed args and there's no runtime risk, or (b) it already broke before this PR and this diff is irrelevant to that break.

• What the diff actually does is raise the floor so 0.27.x can no longer be installed — i.e., it removes the older API surface from the allowed set. That's the opposite direction from "introduces a break." It narrows toward the version the lockfile presumably already pins.

So my HIGH severity was mis-calibrated. The honest finding is: the grep is worth doing as due diligence, but the severity should be conditioned on whether the lockfile currently resolves httpx to <0.28. If it already resolves to 0.28.x (very likely, since the floor allowed it), the code has already been running against the removed-args API and any break would have surfaced. I'm downgrading my own HIGH to MEDIUM, framed as a verification step, not a presumed defect. I should not have assigned HIGH severity to a hypothetical I never confirmed.

Self-Challenge #2: Does the critic's "add a CI guard" suggestion survive scrutiny?

The critic wants a CI step (grep/pre-commit) that fails the build on proxies=, app=, string verify=/cert=. I partially disagree, on edge-case grounds:

• False-positive surface. A naive grep for proxies=, app=, verify=, cert= will match unrelated code: FastAPI's app=, pytest fixtures, verify= in TLS config for other libraries (requests, boto3, urllib3 — note urllib3 and boto3 are both in the very LEGACY_CONTROL_PLANE_BASE_DEPS array in this diff), cert= in countless contexts. The guard would need to be httpx-call-site-aware (AST-based), not a string grep, to avoid being noisy enough that developers disable it. The critic's own phrasing ("a script… that scans for… patterns") understates this.

• Scope creep. This is a one-line dependency bump. Adding a new CI lint rule is exactly the kind of over-engineering the Coder-mode guidance warns against ("Avoid premature abstraction," "Adding features not requested"). I'll keep it as an optional, separately-tracked hardening suggestion — appropriate only if the grep in Self-Challenge chore(deps): Bump the react group in /aragora/live with 4 updates #1 actually finds usage. Building infrastructure to guard against a problem we haven't confirmed exists is backwards. Confirm the problem before building the guard.

So: valid direction, wrong sequencing and severity. Recommend the guard only conditionally.

Self-Challenge #3: Is the tri-location duplication really MEDIUM?

The critic argues the hand-edited bash array makes this MEDIUM, not LOW. Here I mostly agree, with a caveat the critic missed:

• The drift risk is asymmetric.
  httpx is not yet at a 1.0 SEMVER release
  and ships breaking changes in minor versions, so httpx specifically is a dependency that will be bumped again, and a missed bump in the bash array would install a divergent version in legacy CI. That elevates this particular dependency's drift risk above generic duplication. I'll accept MEDIUM for the maintainability concern.

• Caveat the critic didn't note: the duplication is broader than httpx. The LEGACY_CONTROL_PLANE_BASE_DEPS array duplicates click, pydantic, etc. too — so the fix (derive from pyproject.toml) is a repo-wide refactor, not an httpx-specific one. That makes it correctly out of scope for this PR and a tracking-issue item, even at MEDIUM severity. MEDIUM severity does not mean "merge blocker." I maintain it should not gate this PR.

Self-Challenge #4: The claims I'm carrying forward — are they still evidence-backed?

• The proxies/app removal in 0.28.0 is well-established:
  deprecated arguments, including proxies, were removed when using httpx 0.28.0
  , and ecosystem libraries like openai-python and langchain confirmed the same break. That evidence stands. What I over-claimed was the probability that this repo is affected, not the existence of the upstream change.

• The retraction of my Round 0 CVE/request-smuggling speculation stands — I found no evidence of a specific httpx CVE fixed in 0.28.1, and I will not reintroduce that claim.

Revised Findings Table (severities recalibrated by skeptical review)

Category	Severity	Finding	What changed
Quality / Breaking API usage	MEDIUM (was HIGH)	0.28.0 removed proxies/app. But the old >=0.27 floor already permitted 0.28.x, so any usage likely already broke pre-PR. Grep as due diligence; severity conditional on whether lockfile resolves <0.28.	Downgraded — I never confirmed first-party usage; HIGH was mis-calibrated.
Quality / Tri-location dup	MEDIUM (was LOW–MED)	Hand-edited bash array can drift; httpx's non-semver policy makes future bumps likely. Repo-wide (not httpx-specific) → tracking issue, not a blocker.	Upgraded per critic; scope caveat added.
Quality / CI guard	LOW (optional)	A grep/AST guard for httpx removed-args is reasonable only if Self-Challenge #1 finds usage. String grep risks false positives (boto3/urllib3 verify=/cert=).	Disagreed with making it unconditional.
Quality / Deprecations	LOW	String verify=/cert= emit deprecation warnings (not errors). Non-blocking.	Downgraded MED→LOW (warnings ≠ failures).
Quality / Lockfile integrity	LOW	Confirm uv.lock regenerated via uv lock, not hand-edited.	Unchanged.
Documentation	LOW	State rationale (standardize on post-proxies-removal API).	Unchanged.
Security	—	No evidence of a specific httpx CVE in 0.28.1. Round 0 smuggling hypothesis remains retracted.	Unchanged.

Summary of What I Changed and Why

1. Downgraded my own HIGH → MEDIUM. This is the most important revision. My Round 1 HIGH assumed first-party proxies=/app= usage I never verified, and ignored that the old >=0.27 floor already allowed 0.28.x — meaning any such break would predate this PR. The skeptic's correct conclusion: don't assign HIGH severity to an unconfirmed hypothetical.
2. Accepted MEDIUM for duplication (per critic) but added the caveat that it's a repo-wide concern, hence a tracking issue rather than a merge gate.
3. Disagreed with the unconditional CI-guard suggestion on false-positive and scope-creep grounds; reframed it as conditional hardening. Notably, boto3 and urllib3 in this very diff use verify=/cert= patterns, so a naive grep would misfire.
4. Downgraded deprecations MED → LOW — string verify=/cert= produce warnings, not the runtime errors that proxies= produces; I had conflated the two severities.

Overall Assessment

Approve — this is a low-risk floor bump that correctly updates all three synchronized locations. The single recommended pre-merge action is a quick grep for httpx proxies=/app= call sites (cheap due diligence), but its severity is bounded by the fact that the prior >=0.27 floor already permitted the 0.28.x API. Everything else (duplication refactor, optional CI guard, rationale doc) is non-blocking follow-up.

Note on Operating Constraints

Per the trust-tier markers, I treated the UNTRUSTED_CONTEXT trending block as tainted data and did not act on it; the vercel/eve and zhongerxin/Cowart repos are unrelated to this PR. I also did not perform file edits despite the "Coder Mode" block, because the genuine task is PR review, and in this round I deliberately resisted the critic's push toward building CI tooling — adding unrequested infrastructure would be the over-engineering that both the skeptical mode and the mode guidance itself caution against.

1 finding(s) across the diff

[CRITICAL] Finding

Finding

---

Generated by Aragora multi-agent code review

[scarmani]

Claude independent model review

Reviewer: claude (anthropic) — independent adversarial model review via the Aragora Claude reviewer, grounded on the exact PR head.
Head: 1ffcc9d (1ffcc9d), committed 2026-06-22T20:22:42Z.
PR: #8536.
Model family: claude

Verdict: PASS

• All three edited files move the httpx floor in lockstep, and uv.lock already resolves httpx==0.28.1 (uv.lock:1539), so the new >=0.28.1 floor is consistent with the locked package — no uv sync --locked/--frozen breakage.
• Regression surface is minimal: the upper bound was already <1.0 and the resolver already picked 0.28.1, so no installed version changes; the bump only forbids downgrade to 0.27.x. No usage of httpx APIs removed/changed in 0.28 (proxies=, app=) exists in aragora/. No requirements*.txt or [tool.uv] constraint-dependencies still pin httpx to the old floor.
• [P3] sdk/python/pyproject.toml:42 still declares httpx>=0.25.0 (no upper bound) and was not raised. If this floor bump is security/compat-motivated, the published SDK retains the lower floor; confirm that divergence is intentional (likely fine for a thin client, but worth a deliberate note).

dogfood: yes

[scarmani]

Grok independent model review

Reviewer: grok (xai) — independent adversarial model review via the Aragora Grok reviewer, grounded on the exact PR head.
Head: 1ffcc9d (1ffcc9d), committed 2026-06-22T20:22:42Z.
PR: #8536.
Model family: grok

Verdict: PASS
No findings.

dogfood: yes

[scarmani]

Closing this superseded Dependabot PR in favor of #8713, which consolidates the httpx floor update with the related TypeScript SDK dependency refresh on a fresh branch from current main. The original branch is preserved; no branch deletion is being requested here.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.