Looks like a possible RFC 2616 MUST violation. Apache seems to be decoding chunks on-the-fly (as it should when client is HTTP/1.0), but also returning wrong content. The bug is probably in handling long extension tokens in chunked encoding. How exactly the content is corrupted is difficult to say without further analysis. Suffice to say that returned content does not match the sent content. See attached trace for details and ways to reproduce. Test case IDs in the trace link to human-oriented test case description and RFC quotes, if available.
Created attachment 4350 [details] test case trace
Created attachment 4351 [details] same test case, but using HTTP/1.1 client; same problem
Created attachment 4354 [details] same problem for request path, where it is even more dangerous
Fixed in modules/http/http_protocol.c r1.465. We will now return a 413 when the line exceeds our maximum line length. Thanks for using Apache HTTP Server!
Reopening the bug since the same violations seem to exist in httpd-2.0.54
Created attachment 15320 [details] response sent to HTTP/1.0 client We cannot tell what part of content (or extension) is being forwarded, but it is not the right part. Note that the proxy dechunked the content (which is fine).
Created attachment 15321 [details] request chunk
Created attachment 15322 [details] response sent to HTTP/1.1 client
Created attachment 20415 [details] response sent to HTTP/1.0 client
Created attachment 20416 [details] 15321: request chunk
Created attachment 20417 [details] 20415: response sent to HTTP/1.0 client
Created attachment 20418 [details] 15322: response sent to HTTP/1.1 client
Likely not to be fixed/addressed in 2.0.x tree, but will consider at a later time.