The jar: protocol now depends on the ability to get a blocking input stream from all protocols in order to write a jar file to disk. The primary protocol that needs this is http.

there are other cool reasons too to implement OpenInputStream for HTTP. Including download which could then pass this stream to a file channel's AsyncWrite.

That's _exactly_ what the jar: protocol wants to do. I suspect that Bill Law wants it for saving to disk too, right?

Right, that's what prompted Gagan's comment, I believe. He and I have discussed this on numerous occasions in the last 2 weeks.

We need this for HTTP save as downloads too. In this case the unknown content type handler (the save as dialog) needs to be able to just hand nsFileTransport::AsyncWrite() an input stream (rather than buffering data then writing it to the nsFileTransport's output stream. This will allow the unknown content type handler to digest data at a rate fast enough (actually in time w/) as to not back up the socket transport.

This is dogfood because we need to able to download large files using the save as dialog.

Putting on the PDT+ radar.

Jud -- please give us a date.

fix checked in 11/23/99 2:25pm pac time

whoops re-opening. wrong bug.

Clearing Fixed resolution due to reopen.

got a code review. waiting for green tree.

fix checked in 11/29/99 8:30pm pac time.

Jud, what would be a suitable testcase for this bug? Saving a file, using http upload, using smartupdate, etc? Thanks dude!

verified

Marked VERIFED FIXED per valeski. Not testable via QA.

Bulk move of all Necko (to be deleted component) bugs to new Networking component.

I'm seeing a problem, on both Mac and Linux, where loading a remote stylesheet (bug 11859), which uses nsHTTPChannel::OpenInputStream(), cause some kind of threading deadlock, which makes the app cease to respond.

OpenInputStream() is implemented. However it requires that the returned stream be read on a seperate thread (because the implementation simply uses AsyncRead() underneath. This needs to be changed. Opening a new bug (22103) that is not protocol specific.

Development issue - Closing