ATS forwards extra carriage returns in header line endings
Hi,
If you send ATS a request with extra carriage returns in header line endings, it forwards them as-is.
For example, if you send the following request:
GET / HTTP/1.1\r\n
Host: echo\r\n
Extra-CRs: \r\r\r\r\n
\r\n
Then, ATS forwards the following:
GET / HTTP/1.1\r\n
Host: echo\r\n
Extra-CRs: \r\r\r\r\n
Client-ip: 172.18.0.1\r\n
X-Forwarded-For: 172.18.0.1\r\n
Via: http/1.1 traffic_server[a24326f7-ff3b-4679-9801-53028b257033] (ApacheTrafficServer/10.2.0)\r\n
\r\n
Note that the extra carriage returns are still present :)
If you send more than 3 extra (4 total) carriage returns in a single header line ending, though, they all get normalized away. Kinda fun.
-Ben
Hi,
I’ve noticed that Apache Traffic Server (tested on v10.2.0) forwards request headers containing extra carriage returns (\r) exactly as received, instead of normalizing them.
Example: Sending this request:
GET / HTTP/1.1\r\n Host: echo\r\n Extra-CRs: \r\r\r\r\n \r\n
results in ATS forwarding:
GET / HTTP/1.1\r\n Host: echo\r\n Extra-CRs: \r\r\r\r\n Client-ip: 172.18.0.1\r\n X-Forwarded-For: 172.18.0.1\r\n Via: http/1.1 traffic_server[a24326f7-ff3b-4679-9801-53028b257033] (ApacheTrafficServer/10.2.0)\r\n \r\n
The interesting bit is that the extra carriage returns are preserved — unless there are 4 or more, in which case ATS normalizes them away.
I wanted to report this because it could have implications for header parsing, normalization, or downstream server behavior.
If this isn’t intended behavior, I’d be happy to investigate and submit a patch or test case. Could you please confirm if this is reproducible on your end and whether it should be addressed?
Hi,
I’ve noticed that Apache Traffic Server (tested on v10.2.0) forwards request headers containing extra carriage returns (\r) exactly as received, instead of normalizing them.
Example: Sending this request:
GET / HTTP/1.1\r\n Host: echo\r\n Extra-CRs: \r\r\r\r\n \r\n
results in ATS forwarding:
GET / HTTP/1.1\r\n Host: echo\r\n Extra-CRs: \r\r\r\r\n Client-ip: 172.18.0.1\r\n X-Forwarded-For: 172.18.0.1\r\n Via: http/1.1 traffic_server[a24326f7-ff3b-4679-9801-53028b257033] (ApacheTrafficServer/10.2.0)\r\n \r\n
The interesting bit is that the extra carriage returns are preserved — unless there are 4 or more, in which case ATS normalizes them away.
I wanted to report this because it could have implications for header parsing, normalization, or downstream server behavior.
If this isn’t intended behavior, I’d be happy to investigate and submit a patch or test case. Could you please confirm if this is reproducible on your end and whether it should be addressed?
Isn't this just exactly what I said in April?