--On December 7, 2005 2:00:19 AM +0100 Ruediger Pluem <[EMAIL PROTECTED]>
wrote:
The patches to mod_proxy_http we identified here on list do indeed work
and are in as r354628.
Sorry for stepping in that late into the discussion, but wouldn't it be
better to fix that after the return from proxy_run_scheme_handler in
mod_proxy?
The error has to be flagged inside the HTTP scheme before the error is
lost. Without this patch, mod_proxy_http returns 'success'
unconditionally. That is clearly wrong and that's what I changed.
I fear that mod_proxy_ajp is affected by the same problem that
is now fixed in mod_proxy_http. This means we put the burden of handling
this in a unified way on each proxy backend module. How about letting the
schema_handler simply return a specific value (DONE or whatever) to
signal that the backend broke in the middle of sending the response and
let mod_proxy handle the dirty work.
That's what it does right now. What would you like to change?
Question: What about sending an
error bucket through the filter chain in case the backend breaks in the
middle of the response
(yes, I know currently too few filters handle this including
mod_disk_cache)?
An error bucket is already sent down the chain when the specific connection
error I hit with the chunked line occurs through HTTP_IN, but that
accomplishes little because the HTTP filters which understand the error
buckets have already gone as the headers have been sent.
FWIW, an error bucket, by itself, would not be enough; the connection close
logic is only implemented well outside of the filter logic. At best, it
has to be an error bucket combined with a returned status code that can be
returned all the way up. -- justin
