The following fix added in 2.3.15 "mod_substitute: To prevent overboarding memory usage, limit line length to 1MB. [Stefan Fritsch]" causes any line in the response body that is over 1MB to be omitted from the response, delivering a partial response, and the following entry is logged "[Fri Feb 21 16:23:46.440472 2014] [substitute:error] [pid 3912:tid 2600] [client 192.168.0.5:62707] AH01328: Line too long, URI /secure/foo/bar/Main.aspx, referer: https://myhost/secure/foo/bar/Main.aspx?evt=2001&src=Main.aspx.2001" Especially considering that Apache still responds with an HTTP 200 status code, I would think the proper response would be for mod_substitute to just return the line without parsing it, because returning a partial response just ends up corrupting the response. I can see the argument that you may not want to return a line if substitutions fail, but I don't think that should be the default behavior or you should at least provide the ability to define the default behavior.
>for mod_substitute to just return the line without parsing it for security reasons as well as corporate image reasons, this might be very dangerous better just fail with a server error (e.g. HTTP 500 or 500.100 or similar value) so that it's obvious that something went wrong with it
In 2.4.11, a new parameter SubstituteMaxLineLength has been added (see http://httpd.apache.org/docs/2.4/mod/mod_substitute.html#substitutemaxlinelength)
Just ran into this. Agree that just returning the un-parsed line is not OK. But returning 200OK is also clearly wrong. Would suggest it should return either 502 or 500 error. The new setting might help avoid it, but if hit it should still not be 200. We hit it when fetching a list from a REST API behind a reverse proxy with mod_substitute enabled. In this case, it treated the whole response body as a single line so we got a 200 OK without a response body. A strange behaviour also was that if fetching N items triggered the error then fetching N-1 would complete in around 600ms but fetching N would take 5-6 seconds (and not have body). Is this expected in this situation, or is it the client waiting for a body that never shows up? Got same behaviour with command line curl and with PostMan.