On 3/6/06, Darin Fisher <[EMAIL PROTECTED]> wrote: > You should only treat the status events as UI level notifications. > They aren't meant to be programmatically used to switch state. > > You can use nsIInputStream::Available to test if the stream is closed. > (If it returns NS_BASE_STREAM_WOULD_BLOCK, then just treat that as > meaning that the stream is not closed yet.) > > By the way, when reading from a socket input stream, you are most > likely reading from a pipe input stream instead.
I am using UNBUFFERED since the buffering didn't seem to help any over what I had to do in my own code. The header parser in nsResponseHeaders alters the buffer so I need to make a copy. rv = aTransport->OpenInputStream(nsITransport::OPEN_UNBUFFERED, 0, 0, getter_AddRefs(instream)); With UNBUFFERED Available() doesn't return any errors. I have discovered that if I get into AsyncWait and Available() is zero, then the socket is closed. I haven't figured out any other way to get into AsyncWait with zero available. It would be nice if Available() would return the socked closed error for this case so that I don't have to rely on the zero available method. Another solution would be for me to directly catch the status change events but I don't think there is an accessible hook for me to do that. I'm writing my code mainly by making small modifications a couple objects in netwerk/protocol/http. I'll post a delta patch when I get things working. I'm making very few changes to the existing code, most changes add new methods to the existing objects. If I need to do anything big I'll build a new external object. -- Jon Smirl [EMAIL PROTECTED] _______________________________________________ dev-tech-network mailing list dev-tech-network@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-network
