> -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.
Yes, of course the scheme handler must signal the proxy handler that the backend broke. Just returning 'success' in this case is of course plain wrong. > >> 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? I would like to set the c->aborted in mod_proxy's proxy_handler after the run_scheme_handler. Reason: 1. We can define a clear interface for the scheme handlers here: If the backend broke before you sent headers just return BAD_GATEWAY and send nothing, if it broke afterwards just return BROKEN_BACKEND (or whatever you like that should be defined for this case). The proxy handler would handle this BROKEN_BACKEND return code and do the 'right' thing (currently setting c->aborted). Thus we do not have the need to put the burden of the details on the schema handler (why I regard it as a burden see 2.) 2. I am not 100% percent happy with the c->aborted approach as the original intention of c->aborted was another one (The connection to the *client* broke not to the *backend*). I admit that I do not see any other approach currently, so we should stick with this, but if we decide to change this later on and we follow 1. then it is much easier to change as we have this code only in *one* location and not in every scheme handler. [..cut..] > 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 Ahh, ok. Thanks for clarification. Regards Rüdiger
