Roy T. Fielding wrote:
No, you understood its purpose correctly. I have no idea what Justin is talking about -- maybe the proxy's connection to the outbound server? c->aborted is only set on the inbound connection when a previous write to that connection has failed.Setting the inbound c->aborted within a filter just to indicate that the outbound connection has died is wrong -- it prevents other parts of the server (that are working fine) from correctly handling the bad gateway response.
I don't fully understand - the problem in question (as I understand it) happens when the backend drops the connection unexpectedly half way through the response.
At this point the frontend connection has already sent a 200 Ok, it's already sent headers like Content-Length, etc, at this point there is no graceful way of handling the error or sending "bad gateway".
The only sane thing to do at this point (as I can see, unless I am missing something) is to abort the frontend connection, mirroring the same behaviour that the backend just did to us. At the same time, modules like Cache needs to be informed things have gone pear shaped, so the cached entry is invalidated.
Or am I missing something? Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
