Duplicate Content-Type Header Parsing Issue

[TUO-Wu]

Version
bfa754e

Platform
Ubuntu 11.4.0-1ubuntu1~22.04

Description
Hello, I may have found a bug in uvicorn's parsing of HTTP requests with duplicate Content-Type header.
RFC 9110 says this:

Although Content-Type is defined as a singleton field, it is sometimes incorrectly generated multiple times, resulting in a combined field value that appears to be a list. Recipients often attempt to handle this error by using the last syntactically valid member of the list, leading to potential interoperability and security issues if different implementations have different error handling behaviors.

Uvicorn does not reject such requests. For example:

POST / HTTP/1.1\r\n
Host: victim.com\r\n
Content-Type: text/plain\r\n
Content-Type: application/json\r\n
\r\n

$ echo -ne "POST / HTTP/1.1\r\nHost: victim.com\r\nContent-Type: text/plain\r\nContent-Type: application/json\r\n\r\n" | nc 172.18.0.3 80
HTTP/1.1 200 OK
date: Thu, 20 Mar 2025 15:35:33 GMT
server: uvicorn
content-type: application/json
Transfer-Encoding: chunked

c1
{"method":"UE9TVA==","version":"MS4x","uri":"Lw==","body":"","headers":[["aG9zdA==","dmljdGltLmNvbQ=="],["Y29udGVudC10eXBl","dGV4dC9wbGFpbg=="],["Y29udGVudC10eXBl","YXBwbGljYXRpb24vanNvbg=="]]}
0

Recipients often attempt to handle this error by using the last syntactically valid member of the list, leading to potential interoperability and security issues if different implementations have different error handling behaviors.

If different implementations have different error handling behaviors, there may be potential interoperability and security issues. So I might suggest rejecting such requests.

[nggit]

Just like HTTP methods, Content-Type can be handled in ASGI app/middleware. ASGI server only cares about Content-Length / Transfer-Encoding.

I think there are more important issues than the one you raised, for example, whether or not to allow leading zeros in Content-Length.

Because Uvicorn seems to allow this in the h11 implementation.

printf 'POST / HTTP/1.1\r\nHost: localhost\r\nContent-Type: text/plain\r\nContent-Length: 001\r\n\nABC' | nc 127.0.0.1 8000

[TUO-Wu]

Ahh, I see what you mean.
But if different recipients (ASGI app/middleware) handle Content-Type differently, it may cause some interoperability and security issues, according to the RFC 9110 I quoted above. So I may still suggest doing some extra checks.

Besides, as for uvicorn allowing leading zeros in Content-Length you mentioned, RFC 9110 says this:

Content-Length = 1*DIGIT

I think 1*DIGIT means "one or more numeric characters", so I think leading zeros should be allowed, as long as it's all numbers. And some mainstream HTTP servers, such as Apache, do accept such Content-Length requests.

Thank you for your response.

[nggit]

But if different recipients (ASGI app/middleware) handle Content-Type differently,

It is very unlikely to happen. The middlewares are doing a different job, not parsing differently like in the HTTP proxy chain.

so I think leading zeros should be allowed,

Then you allow the possibility of smuggling.