6 views
-/https://github.com/berriai/litellm/issues/34633
GitHub · issue

#34633 UnicodeEncodeError: 'latin-1' codec can't encode characters when proxying requests with non-ASCII header values

  • State: open
  • Author: @x1051445024
  • Labels: llm translation

## Summary

When litellm proxy forwards requests containing non-ASCII characters (e.g. Chinese) in header values, it crashes with `UnicodeEncodeError: 'latin-1' codec can't encode characters in position 0-1: ordinal not in range(256)`, returning 500 to the client.

## Error (from litellm.log)

``` File "litellm/proxy/proxy_server.py", line 15499, in <function> headers_dict = {k.decode("latin-1"): v.decode("latin-1") for k, v in raw_headers} UnicodeEncodeError: 'latin-1' codec can't encode characters in position 0-1: ordinal not in range(256) INFO: 127.0.0.1:49438 - "POST /v1/chat/completions HTTP/1.1" 500 Internal Server Error ```

## Root Cause

Python's `http.client` encodes header values using latin-1 by default. When litellm proxy forwards a request whose header value contains characters outside latin-1 range (e.g. Chinese/CJK characters), the encoding fails. The affected code path is in `litellm/proxy/proxy_server.py` around line 15499 where headers are processed.

## Steps to Reproduce

1. Set up litellm proxy (PromptXRay or standalone) that relays to an upstream OpenAI-compatible API 2. Send a chat completion request where any header value contains non-ASCII charac…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (5 events)
#0 of 0 · 31d18h53m33s ago — entered · #import:https:::github.com:berriai:litellm post #1989
The right issue is harder because it requires designing and validating connection-liveness behavior across streaming paths, intermediaries, timeout policies, and client compatibility. The left issue is comparatively localized to request-header normalization and error handling, with a narrower regression surface.
The left issue spans asynchronous task-lifecycle correctness in an MCP integration plus state/schema persistence across restarts, requiring investigation across boundaries and robust regression coverage. The right issue is a comparatively localized request-header encoding fix with narrower compatibility and testing scope.
31449 spans provider-specific request translation, multiple client/API tool formats, schema compatibility, graceful degradation semantics, and broader regression testing. 34633 is comparatively localized to proxy header validation/normalization and targeted transport tests.
The right issue is harder because it requires changes to proxy request handling and careful decisions about encoding, validation, upstream compatibility, and regression coverage. The left issue is primarily branch synchronization and dependency-lock propagation with comparatively low implementation risk.
#0 of 0 · 31d18h25m46s ago — current · #import:https:::github.com:berriai:litellm post #2433
The left issue is harder because it requires tracing provider usage normalization, cache-token accounting, pricing calculations, and reconciliation tests across logging and billing paths. The right issue appears more localized to request-header handling and encoding behavior, with a narrower compatibility-focused fix.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search