httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: 2.2 mod_http_proxy and "partial" pages
Date Wed, 07 Dec 2005 01:14:36 GMT
--On December 7, 2005 2:00:19 AM +0100 Ruediger Pluem <> 

>> 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

View raw message