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
