On 12/13/2016 12:18 PM, Ruediger Pluem wrote:
Have a look at line 1334 of mod_proxy_http.c:
Okay, that's starting to make some more sense. Thanks!
On 12/13/2016 11:37 AM, Ruediger Pluem wrote:
After this patch we do the wrong thing with an EOC bucket.
The current contract is that an EOC bucket *anywhere* in the brigade causes the
header filter to go out of the way. After the patch this is broken if
a bad header is present. But as EOC tells us to get out of the way and do
nothing,
we don't need to take care about bad headers.
As I understand it:
- the case you're discussing happens when we're proxying to an upstream
HTTP server, *and* this is at least the second request on this
particular client connection, *and* we fail to get a status line from
upstream, *and* somehow an invalid header gets set (perhaps with the
Header directive)
- the new behavior from the client side is that, instead of the
connection simply dropping out with no response, we send a 500 and
*then* drop the connection.
Whether this is broken behavior from the outside looking in, I'm not
sure -- an invalid header in this situation implies there's been a
misconfiguration; why not send a 500? -- but your point about the
internal API contract stands.
There's also the other question you seem to be raising -- do we need to
check headers and 500 an outgoing response if no headers are actually
going to be sent? IIUC, this same question also applies to the HTTP/0.9
code path.
--Jacob
