uvicorn: WebSocket headers encoding problem

Checklist

The bug is reproducible against the latest release and/or master.
There are no similar issues or pull requests to fix it yet.

Describe the bug

If there is a websocket connection with a non-ascii char in header, the server will explode. The problem seems to be from here: https://github.com/encode/uvicorn/blob/9dc5a43209fe081ba3e74135189252bfddf75587/uvicorn/protocols/websockets/websockets_impl.py#L102 Also, I checked the ASGI doc and in section 2.2.5 it states:

These are byte strings of the exact byte sequences sent by the client/to be sent by the server. While modern HTTP standards say that headers should be ASCII, older ones did not and allowed a wider range of characters. Frameworks/applications should decode headers as they deem appropriate.

So, I think uvicorn should allow for non-ascii chars in header. It is definitely the only reason that we can’t use uvicorn in production yet.

To reproduce

Expected behavior

Doesn’t explode.

Actual behavior

Explodes with an exception.

Debugging material

Environment

OS / Python / Uvicorn version: just run uvicorn --version
The exact command you’re running uvicorn with, all flags you passed included. If you run it with gunicorn please do the same. If there is a reverse-proxy involved and you cannot reproduce without it please give the minimal config of it to reproduce.

Additional context

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 17 (11 by maintainers)

Most upvoted comments

Yes, this can be done so though User-Agent is not the only header with this problem. And we can not replace them all. Some of the headers are useful for backend and can not be just removed.

M1ha-Shvn on Jul 19, 2023

I also faced this problem, using uvicorn under NGINX proxy. NGINX bypasses unicode headers without errors. In my case I sometimes get Origin as domain on local language or User-Agent header, with unicode characters, which are translated to ‘\uxxx’. Header example: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5 (Erg\udce4nzendes Update)) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 Safari/605.1.15 The real world problem is, that I can do nothing with these errors. These headers are formed by user browsers, handled by websocket implementation before I can handle it anyhow in FastAPI code. So I can not raise correct validation error or anything else… I agree with threads’ author that there should be some kind of callback/hook that will help developers to process these errors and make respsective correct API response

M1ha-Shvn on Feb 27, 2023

@lavandosovich - I’d be happy to spend a little time thinking about this if we start from really basic first principles.

Can you give an example of an HTTP response that you’d like to be able to send, that you currently can’t because of this limitation?

tomchristie on Dec 9, 2022