Working on bug 772, I've tracked it down thusly: When we call initiateClose, we dont fully free the BodyReader, because the one on conn is preserved. If we dont fully free it, then we dont discard the body, it just spools forever because theres no callback.
If we do free the bodyreader, we trigger an assert because the abort function expects to be called only once. I dont see any unit tests for icap's dependence on the API, so I haven't changed BodyReader to address this, what I am doing is poking into it from ConnStateData - calling consume on the aborted bytes - as that seemed the easiest fix to me. I think a better api for the BodyReader would be an explicit 'abort()' call, which once called would continue to read, discarding the data without needing a callback. -Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>.
signature.asc
Description: This is a digitally signed message part
