On Dec 16, 2005, at 12:41 AM, Plüm, Rüdiger, VIS wrote:
I do not intend to do close the connection by myself. Currently it will be closed because c->keepalive is set to AP_CONN_CLOSE (a approach also suggested in Roys patch).
Right, the important bit is that the code managing the client connection is what should close the client connection, not the code that is managing the outbound (server) connection. For all we know, the client connection might be an SMTP notifier. If we wanted to get really fancy, we could check to see if the response code has been sent yet and change the whole response to a 502 bad gateway, but that probably isn't worth the effort.
The only addition I want to make is that in the chunked case the chunked filter should not sent the closing chunk to make it clear to the client that something had broken.
I agree with that change.
The question that remains to me: Does it hurt that the core output filter removes the error bucket once it has seen it?
I have no idea. I looked at the filtering code and the way it uses error buckets (in fact, the only place that uses error buckets) and I don't understand why it was written this way at all. It is more efficient to just use the EOS bucket data to indicate an error in all of those cases, since they all result in an EOS anyway and we just waste memory/time with the special bucket type. ....Roy
