On Tue, Dec 13, 2016 at 6:42 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
> On Tue, Dec 13, 2016 at 8:37 PM, Ruediger Pluem <rpl...@apache.org> wrote: > > > > This change is also unrelated to the bad header issue and I think > > if there is interest to address this it should be done in a separate > > patch set. > > It is actually, we could eventually avoid reading/consuming the body > of the original response (closing prematuraly any backend > connection...), but in any case we need to eat the ap_die()'s one if > we encounter a bad header on its generated response. > That's because we want to generate a minimal 500 response in this > case, with no body (even the ap_die(500)'s one not be related, > ErrorDocument can be any redirection, including proxying). > > Thus the eat-body code is needed anyway, let's also use it for the > original response then Indeed but we have to reiterate one point Fielding has raised in another forum that seems to be ignored in this conversation. In light of bad input, the http servers and user agents must present valid data to their upstream servers and downstream consumers. The spec does not define how this is accomplished, the entire response can be redacted, or the invalid headers can be redacted. No consumer can be presented with invalid request or response data. How we choose to accomplish this is entirely our choice, that was Roy's point. I took the following statement literally and accepted Yann's proposal; "This is still not great. We get the original body, a 500 status code and status line." Any 500 status with the original body would be completely nonsense, and I didn't even test to confirm that this earlier assertion was true, I just assumed the statement was accurate. But it could still be the original status with all garbage response headers redacted. It could be a proper 500 response and let httpd's mechanisms to kill the request, letting the handler still dump useless data at the filter stack does work (confirmed). Provided it presents the correct error body, and redacts bad headers at every phase, we deliver a comprehensible response in any case. Best yet, we inform the caller that the send brigade call failed, and let smart callers short-circuit streams that they are able to. As a practical matter, we can't do that in the proxy, since the entire response body must be eaten to ensure correct socket closure. But the direct response to the caller could and should be issued directly. Right now, we have Yann's proposal. Several of us would like to see patches attached to these concerns with a cleaner solution. I'm not clear that the filter stack was conceived as the origin of error responses, but this case, and many other conceivable examples proves that we should have considered that case, and made the programming pattern a little clearer.
