trafficserver icon indicating copy to clipboard operation
trafficserver copied to clipboard

ATS forwards extra carriage returns in header line endings

Open kenballus opened this issue 8 months ago • 2 comments

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

kenballus avatar Apr 16 '25 23:04 kenballus

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?

BharathPESU avatar Nov 04 '25 18:11 BharathPESU

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?

kenballus avatar Nov 04 '25 18:11 kenballus