httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Akins <bak...@web.turner.com>
Subject Re: AW: 2.2 mod_http_proxy and "partial" pages
Date Thu, 08 Dec 2005 13:31:18 GMT
Graham Leggett wrote:

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

I agree.  There is no way we can inform the client of the problem. 
Currently,

- we just cease sending the client data.
- The client is rather confused
- other modules think the request completed successfully.


If we c->aborted:
- we just cease sending the client data.
- we close connection to client
- The client is rather confused
- other modules know that the request was aborted and can react


So, currently, we would have to change multiple modules to notice some 
other error notification.  Meanwhile, the client gains nothing.  So, I 
say, just use c->aborted


Another option, possibly even more evil, is to have another field in 
request_rec (or somewhere easy) that notes that the server (us or the 
backend) is causing the termination and not the client. Or make 
r->aborted have multiple values like c->keepalive:

#define AP_NOT_ABORTED 0
#define AP_CLIENT_ABORTED 1
#define AP_ORIGIN_ABORTED 2
#define AP_INTERNAL_ABORTED  3


most modules could still just check for r->aborted.  You could call that 
"legacy support."  New modules, if they desired, could react differently 
depending on actual value.

Thoughts?
-- 
Brian Akins
Lead Systems Engineer
CNN Internet Technologies

Mime
View raw message