chore(deps): bump tower-http from 0.6.11 to 0.7.0

[dependabot]

Bumps tower-http from 0.6.11 to 0.7.0.

Release notes

Sourced from tower-http's releases.

tower-http-0.7.0

Changes since 0.6.11

Added

• csrf: add cross-site request forgery (CSRF) protection middleware, porting the cross-origin protection scheme introduced in Go 1.25 (#699)

  use tower::ServiceBuilder;
  use tower_http::csrf::CsrfLayer;
  // Rejects cross-origin state-changing requests using Sec-Fetch-Site,
  // an Origin allow-list, and an Origin/Host fallback. No per-request
  // token state required.
  let layer = CsrfLayer::new().add_trusted_origin("https://example.com")?;
  let service = ServiceBuilder::new().layer(layer).service_fn(handler);

• timeout: add DeadlineBody for non-resetting body timeouts, applied via the new RequestBodyDeadlineLayer and ResponseBodyDeadlineLayer (#688)

  Unlike TimeoutBody, which resets its deadline on every frame, DeadlineBody caps the total time of a body transfer. A slow client trickling one byte at a time never trips an idle timeout but will trip a deadline.

  use std::time::Duration;
  use tower::ServiceBuilder;
  use tower_http::timeout::RequestBodyDeadlineLayer;
  // Abort the request body transfer after 30s total, regardless of how
  // frequently data arrives.
  let service = ServiceBuilder::new()
  .layer(RequestBodyDeadlineLayer::new(Duration::from_secs(30)))
  .service_fn(handler);

• fs: add strong ETag support to ServeDir, including If-Match and If-None-Match precondition handling per RFC 9110. 304 Not Modified responses now carry the ETag and Last-Modified validators (#691)

• fs: add a Backend trait to make ServeDir work with non-filesystem sources (e.g. embedded assets or object storage). The default TokioBackend preserves existing behavior. Use ServeDir::with_backend() to plug in custom implementations (#684)

  use tower_http::services::fs::ServeDir;
  // MyBackend implements tower_http::services::fs::Backend.
  // The default ServeDir::new() continues to use TokioBackend (local FS).
  let service = ServeDir::with_backend("assets", MyBackend::new());

• fs: add html_as_default_extension option to ServeDir, appending .html when the request path has no extension (#519)

• fs: add redirect_path_prefix option to ServeDir, prepending a prefix on trailing-slash redirects so the service can be mounted under a sub-path (#486)

• validate-request: add ValidateRequestHeaderLayer::has_header_value() to reject requests when a header does not have an expected value (#360)

• body: UnsyncBoxBody::new() constructor and From<ServeFileSystemResponseBody> conversion to avoid double-boxing when combining ServeDir responses with other body types (#537)

• limit: implement Default for limit::ResponseBody when the wrapped body also implements Default (#679)

Changed

... (truncated)

Commits

• b194fcf v0.7.0
• af828a6 feat(follow_redirect)!: preserve request extensions across redirects (#706)
• 8cb8d99 feat(ValidateRequestHeaderLayer): add has_header("...").with_value("...") fun...
• 3b56d2d feat!: Add configurable Backend trait for ServeDir, bump MSRV 1.65 (#684)
• 8508716 Add redirect_path_prefix option (#486)
• 56327b2 Add Windows drive-prefix path regression test (#705)
• 54c6db8 feat(compression)!: upgrade SizeAbove threshold from u16 to u64 (#704)
• 68cd6d8 Add DeadlineBody for non-resetting body timeouts (#688)
• fa8a98c feat(fs): add strong ETag support to ServeDir (#691)
• 36d2205 fix: Make SetMultiple*Header Clone for !Clone http bodies (#703)
• 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)

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Concerns	0 (none)
Heuristic	0.0s
Duplication	0.0s
Interrogation	733.6s (2 bridge agents)
Total	733.6s

💰 Value — sound

Routine workspace dependency bump of tower-http 0.6→0.7 touching one line in Cargo.toml; uses only stable middleware APIs and follows the existing centralized-version pattern.

• What it does: Bumps the workspace-level tower-http dependency from 0.6 to 0.7 in the root Cargo.toml (line 255), updating the lockfile. tower-http 0.7.0 adds CSRF protection middleware and non-resetting DeadlineBody timeouts, and pulls updated transitives (socket2 0.6.3, windows-sys/core bumps). The codebase consumes only the cors, trace, request-id, and sensitive-headers features across 4 crates.
• Goals it achieves: Keeps a core HTTP middleware dependency current with upstream releases, gaining access to new features (CSRF layer, DeadlineBody) and picking up transitive security/maintenance updates (socket2, windows-sys).
• Assessment: A clean, minimal dependency bump. The workspace already centralizes the version in root Cargo.toml:255 and each crate consumes it via { workspace = true }, so this is exactly the right single-line change point. All consumed APIs (CorsLayer, TraceLayer, MakeRequestUuid/PropagateRequestIdLayer/SetRequestIdLayer, SetSensitiveRequest/ResponseHeadersLayer) are stable surfaces unlikely to break across
• Better / existing approach: none — this is the right approach. Searched all tower_http usages (5 import sites in 2 source files) and all 4 Cargo.toml feature declarations; nothing to reuse or extend differently. The bump follows the established workspace pattern.
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content

🎯 Usefulness — sound

Clean minor-version bump of tower-http 0.6→0.7; all four consumers use only stable features/types that survive the bump unchanged, and none of the 0.7 breaking changes touch the codebase's surface.

• Integration: The version pin flows from workspace Cargo.toml:255 into all four crate manifests (crates/auth, crates/x402, crates/tangle-aggregation-svc, crates/pricing-engine) which each request features via workspace = true. Verified each requested feature (cors, trace, request-id, sensitive-headers) and each imported type exists in the local tower-http 0.7.0 source. The HTTP middleware these layers provide i
• Fit with existing patterns: tower-http is the canonical HTTP middleware for the axum/tonic stack this workspace already builds on; this is a routine version refresh, not a competing pattern. No equivalent in-repo middleware exists to duplicate.
• Real-world viability: The 0.7.0 CHANGELOG lists five breaking changes (compression wildcard/SizeAbove, no-op feature removal, trace/classify GrpcCode non_exhaustive, follow-redirect extension forwarding, fs trailing-slash). Cross-checked every one against actual usage: the codebase enables none of compression/fs/follow-redirect, does not construct GrpcCode/GrpcFailureClass (uses TraceLayer::new_for_http() high-level bu
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

No concerns — sound change, no better or existing approach found. ✅

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260713T122251Z}

[tangletools]

⚠️ Review Interrupted — a20eeab3

The review runner stopped before publishing a final verdict: webhook_restarted.

State	Detail
Interrupted	webhook restarted

No review verdict was produced for this run. Trigger a fresh review on the current PR head if the PR is still open.

_{tangletools · #1473 · model: kimi-for-coding · updated 2026-07-13T12:31:08Z}

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Concerns	0 (none)
Heuristic	0.0s
Duplication	0.0s
Interrogation	51.3s (2 bridge agents)
Total	51.3s

💰 Value — sound

Routine workspace-wide bump of tower-http 0.6 → 0.7 via the shared workspace dependency; done correctly, no code changes needed.

• What it does: Bumps the workspace tower-http dependency from 0.6 to 0.7 in Cargo.toml:255 and regenerates Cargo.lock (new 0.7.0 entry at lock line ~14733, plus transitive bumps to socket2 0.6.3 and windows-sys/windows-core). No source changes.
• Goals it achieves: Stay current with tower-http; pick up 0.7's additions (CsrfLayer, DeadlineBody timeouts) and transitive security/compat updates (socket2, windows-sys) without changing any call sites.
• Assessment: Correct and minimal. The four consumers (crates/auth, crates/x402, crates/pricing-engine, crates/tangle-aggregation-svc) only use the cors, trace, request-id, and sensitive-headers features — all stable APIs unchanged across 0.6→0.7, so no source edits are required or expected. Bumping once at the workspace dependency (Cargo.toml:255) and letting crates inherit via workspace = true is exactly th
• Better / existing approach: none — this is the right approach. Verified the workspace-deps pattern (Cargo.toml:255) is the single source and all four crates use { workspace = true }, so one-line bump + lockfile regen is the correct minimal shape.
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content

🎯 Usefulness — sound

Routine, well-scoped tower-http 0.6.11→0.7.0 bump that keeps existing call sites working and adds no dead surface; new 0.7 capabilities are additive and land ahead of any caller, which is fine.

• Integration: Already wired and reachable: tower-http is consumed by 4 crates (crates/auth/Cargo.toml:18, crates/x402/Cargo.toml:40, crates/tangle-aggregation-svc/Cargo.toml:15, crates/pricing-engine/Cargo.toml:76) and exercised in code at crates/auth/src/proxy.rs:21-26 and crates/pricing-engine/src/service/rpc/server.rs:16. The bump only changes Cargo.toml:255 and Cargo.lock; all imported APIs (CorsLayer, Trac
• Fit with existing patterns: Fits the established pattern exactly: workspace-level dependency declaration in Cargo.toml:255 with default-features=false, per-crate feature enablement via { workspace = true, features = [...] }. No competing or duplicate HTTP-middleware abstraction exists in the tree. Grep for CorsLayer/TraceLayer shows tower-http is the single source for these layers.
• Real-world viability: The APIs used (CORS, trace, request-id, sensitive-headers) are battle-tested and unchanged in 0.7.0; transitive bumps (socket2 0.5→0.6, windows-sys, windows-core) are routine. No new behavior is enabled by this PR — it is a pure version lift — so there is no new happy-path/edge-case surface to validate beyond confirming the existing build passes, which the existing CI gate (cargo build --workspace
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

No concerns — sound change, no better or existing approach found. ✅

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260713T124814Z}

[tangletools]

✅ No Blockers — a20eeab3

Review health 100/100 · Reviewer score 95/100 · Confidence 70/100 · 0 findings (none)

glm: Correctness 95 · Security 95 · Testing 95 · Architecture 95

Reviewer score is advisory once the run is complete and the verdict has no blockers.

Full multi-shot audit completed 2/2 planned shots over 2 changed files. Global verifier still owns final merge decision.

No findings.

---

_{tangletools · 2026-07-13T13:28:18Z · trace}

[tangletools]

✅ Clean — a20eeab3

Full multi-shot audit completed 2/2 planned shots over 2 changed files. Global verifier still owns final merge decision.

Full immutable report for this review: trace

Summary comment for this run: full summary

---

_{tangletools · 2026-07-13T13:28:18Z · immutable trace}