On Dec 8, 2005, at 9:21 PM, Justin Erenkrantz wrote:
Even with an EOS bucket, how will we indicate that the connection
should be
aborted? (i.e. don't try to do any further writes?)
The inbound connection hasn't been aborted -- only the outbound.
We don't even want to abort the inbound connection until the client
has received as much of the response as we received, since that
will help the client diagnose the error. The only thing we need
to do is invalidate the cache entry, which would be done when
mod_*_cache checks the EOS bucket (which it already does)
for an error (the new feature).
I would extend the EOS bucket data to be an errno and then have
mod_cache check for that data != 0 when it does its EOS check.
For httpd's filters, an EOS bucket data doesn't attempt a close of the
stream: in fact, EOS doesn't do anything to the socket. By the
time we
start writing the body, all of the filters that know HTTP are long
gone.
(The only thing that might be left is a chunking output filter.)
Plus,
with apr's bucket types, there is no mechanism to associate that
type of
error condition.
No, but we can graft it onto the currently unused EOS bucket data.
I am surprised it wasn't implemented that way in the first place.
I am too, but I'd like to be able to resolve this veto without
radically
having to redesign filters in httpd. =)
Me too -- I'll see what I can come up with during the hackathon.
When I looked at it earlier, a fix seemed feasible with only two
lines of code plus whatever log messages are desired.
FWIW, serf doesn't have these sorts of problems; that's one of the
(many)
things we corrected with serf's filter design. -- justin
Yes, but will it be done before waka? ;-)
....Roy
