litellm - 💡(How to fix) Fix [Feature]: Per-deployment option to drop specific inbound client headers [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#28238Fetched 2026-05-20 03:40:42
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Participants
Timeline (top)
labeled ×4closed ×1

Code Example

model_list:
    - model_name: claude-opus-4-7
      litellm_params:
        model: bedrock/anthropic.claude-opus-4-7-v1:0
        additional_drop_headers:
          - authorization
          - anthropic-beta
          - anthropic-version

---

Invalid key=value pair (missing equal-sign) in Authorization header
(hashed with SHA-256 and encoded with Base64): '…='
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

The Feature

Add an additional_drop_headers field to litellm_params in model_list entries, mirroring the existing additional_drop_params pattern.

  model_list:
    - model_name: claude-opus-4-7
      litellm_params:
        model: bedrock/anthropic.claude-opus-4-7-v1:0
        additional_drop_headers:
          - authorization
          - anthropic-beta
          - anthropic-version

Scope (important): this only filters headers that were forwarded from the client → LiteLLM (typically via forward_client_headers_to_llm_api: true).

It does not touch any headers LiteLLM itself generates when calling the upstream provider (e.g. AWS SigV4 Authorization, the provider's own auth, anthropic-version set by the Anthropic transformer, etc.). So request-building / signing on the LiteLLM → upstream leg is unaffected.

Motivation, pitch

With forward_client_headers_to_llm_api: true, headers a client sends to LiteLLM are carried through to backend calls including the fallback call. That's where cross-provider conflicts surface.

Concrete example we hit in production:

  1. Claude Code authenticates via Claude subscription OAuth, sends Authorization: Bearer sk-ant-oat01-... to LiteLLM.
  2. Primary anthropic/claude-opus-* succeeds → subscription quota is consumed.
  3. On rate_limit_error, the router falls back to bedrock/anthropic.claude-opus-*.
  4. The same client Authorization header is still in the request data on the fallback hop. AWS SigV4 signing collides with the pre-existing Bearer value, and Bedrock rejects
Invalid key=value pair (missing equal-sign) in Authorization header
(hashed with SHA-256 and encoded with Base64): '…='

What part of LiteLLM is this about?

Proxy

LiteLLM is hiring a founding backend engineer, are you interested in joining us and shipping to all our users?

No

Twitter / LinkedIn details

https://www.linkedin.com/in/%EC%84%B8%ED%99%98-%EA%B9%80-a31543202/

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING