On Mon, Dec 12, 2016 at 3:07 PM, Jacob Champion <champio...@gmail.com> wrote:+ > > > What's the case where this catches recursion that the previous logic in > r1773861 did not handle? I'm trying to write a test that fails on r1773861 > and succeeds on r1773865, but I haven't figured it out yet.
I'm confused by a different aspect. In trashing the body-in-flight, whose headers caused us to 500-reject the response, have we also trashed any and all correct error documents or built-in short 500 response explanation? Unlike a 400-reject (which is always caused by a badly implemented client, and should never arrive from a conventional browser user-agent), the 500-reject speaks to some module or backend that isn't under the requestor's control. An error doc may be quite helpful in this situation. I've verified that the bad headers in the current patch are redacted looking at wireshark capture. Only one (first) bad header is logged, which is fine IMO, no need for excessive error.log noise.
