Closed Bug 18434 Opened 21 years ago Closed 20 years ago

[Dogfood]Need to implement nsHTTPChannel::OpenInputStream

Categories

(Core :: Networking, defect, P3)

All
Other
defect

Tracking

()

CLOSED FIXED

People

(Reporter: warrensomebody, Assigned: jud)

References

Details

(Whiteboard: [PDT+] 12/3)

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.
Blocks: 12579
Target Milestone: M12
Status: NEW → ASSIGNED
Summary: Need to implement nsHTTPChannel::OpenInputStream for jar: protocol → Need to implement nsHTTPChannel::OpenInputStream
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.
Blocks: 18725
Summary: Need to implement nsHTTPChannel::OpenInputStream → [Dogfood]Need to implement nsHTTPChannel::OpenInputStream
Whiteboard: [PDT+]
Putting on the PDT+ radar.
Assignee: gagan → valeski
Status: ASSIGNED → NEW
Jud -- please give us a date.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] 11/26
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
fix checked in 11/23/99 2:25pm pac time
whoops re-opening. wrong bug.
Status: REOPENED → ASSIGNED
Clearing Fixed resolution due to reopen.
Resolution: FIXED → ---
Whiteboard: [PDT+] 11/26 → [PDT+] 11/26 awaiting code review
Whiteboard: [PDT+] 11/26 awaiting code review → [PDT+] 12/3
got a code review. waiting for green tree.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
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!
Status: RESOLVED → VERIFIED
verified
Marked VERIFED FIXED per valeski.  Not testable via QA.
Blocks: 21564
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
Status: VERIFIED → REOPENED
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.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
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.
No longer blocks: 11859
Status: RESOLVED → CLOSED
Development issue - Closing
No longer blocks: 21564
You need to log in before you can comment on or make changes to this bug.