ATS forwards malformed empty `Content-Length` headers, in violation of RFC 9110

[kenballus]

Description

RFC 9110 defines the following ABNF rule for the acceptable values in a Content-Length header:

Content-Length = 1*DIGIT

(i.e. 1 or more ASCII digits, so empty values are invalid)

A few paragraphs later, it says this:

Likewise, a sender MUST NOT forward a message with a Content-Length header field value that does not match the ABNF above, with one exception: a recipient of a Content-Length header field value consisting of the same decimal value repeated as a comma-separated list (e.g, "Content-Length: 42, 42") MAY either reject the message as invalid or replace that invalid field value with a single instance of the decimal value, since this likely indicates that a duplicate was generated or combined by an upstream message processor.

Thus, ATS is obligated to reject (or at least, not forward) requests that do not match that ABNF rule.

However, ATS currently forwards empty Content-Length headers as-is, which is a violation of the RFC.

To reproduce

1. Build and start ATS master on port 80, along with a logging webserver of your choice on port 8000.
2. Send the following request to port 80:

GET / HTTP/1.1\r\n
Host: whatever\r\n
Content-Length: \r\n
\r\n

3. Observe that it forwards the invalid CL header as-is to your backend server, without correction or rejection.

Config

/usr/local/etc/trafficserver/records.yaml

ts:
  http:
    server_ports: 80 80:ipv6

/usr/local/etc/trafficserver/remap.config

map / http://127.0.0.1:8000

Versions

ATS: master branch, commit e6182d9
OS: Debian Bookworm container running on top of Arch Linux with a 6.4.3 kernel

[masaori335]

Thanks for the report. I agree that the empty value Content-Length header is a malformed header.