300889 - Does nsIHttpChannel.open() method work asynchronous?

Status: VERIFIED INVALID

(Core :: Networking, defect)

Description

[alexander :surkov (:asurkov)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; ru-RU; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 (ax)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; ru-RU; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 (ax)

I get xml file by httpchannel.open() method. When I read returned istream then
isream contains a part of xml file. When I show alert message before reading of
istream then istream contains xml file wholly.

//gets a part of xml file
var istream=nsIHttpChannel.open();
var
iistream=Components.classes["@mozilla.org/scriptableinputstream;1"].createInstance(Components.interfaces.nsIScriptableInputStream);
iistream.init(istream);
var rep=iistream.read(iistream.available());
alert(rep);

//gets xml file wholly.
var istream=nsIHttpChannel.open();
alert('hello'); //note
var
iistream=Components.classes["@mozilla.org/scriptableinputstream;1"].createInstance(Components.interfaces.nsIScriptableInputStream);
iistream.init(istream);
var rep=iistream.read(iistream.available());
alert(rep);

Reproducible: Always

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

there is no guarantee that the entire file can be read in a single call to
read(). call it multiple times, until it returns no data (0 bytes).

Comment 2

[Darin Fisher]

v.

Comment 3

[alexander :surkov (:asurkov)]

If stream.available() is less then requested file length then stream doesn't
contain file content a wholly. Does it mean channel.open() works asynchronous?
If no then how it can be expained?

Note if I show alert message before reading stream then stream.available()
equals file length. If I read file without any messages then stream.available()
returns a number lesser than file length.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

> Does it mean channel.open() works asynchronous?

the stream is filled from a background thread, if that's what you mean.
(actually, I think for some channels that's not true, but the effect is almost
the same)

this behaves a lot like the C read() function, except that it doesn't really
have an available() equivalent.

> Note if I show alert message before reading stream then stream.available()
> equals file length.

yeah, presumably that gives necko enough time to load the entire file...

Comment 5

[alexander :surkov (:asurkov)]

I'm sorry if bug was fixed then where can I find a patch?

Comment 6

[Darin Fisher]

This bug should be marked INVALID.  No patch was applied to the source.  The
initial report is invalid.  Write code like this:

  var n, data = "";
  while ((n = iistream.available()) != 0) {
    data += iistream.read(n);
  }

reopening so i can mark this bug invalid.

Comment 7

[Darin Fisher]

INVALID

Comment 8

[alexander :surkov (:asurkov)]

Why intitial report is invalid?

From the point of view of xul programmer open() method works asynchronous
because istream.available() returns number lesser then length of file content.
When I use file channel I can't get the such problem. 

While stream is filled from a background thread, I can't use DOMParser object
(parseFromStream() method) since stream doesn't contain file a wholly. Maybe
parseFromSteam() should use code like you proposed in comment#6?

Comment 9

[alexander :surkov (:asurkov)]

I have in view when open() method returns stream then stream must contain a file
entirely. Why do you think it's not obligatory request?

Comment 10

[Darin Fisher]

The bug is invalid.  Read the documentation for nsIInputStream.  Also, consider
a file that is larger than 4 gigabytes in length.  nsIInputStream::available()
returns a 32-bit integer, which cannot represent the full length of a file
larger than 4 GB.  So, it is important to anticipate available() returning only
part of the file.  The behavior of a local file stream (from a file:// URL) is
consistent with this prescribed behavior.

It sounds like you may have discovered a bug with the DOMParser, so I would
recommend filing a bug against that component.  This bug as described in comment
#0 is invalid.  Please do not reopen this bug.

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #5)
> I'm sorry if bug was fixed then where can I find a patch?

sorry, I accidentally clicked FIXED, I meant to mark it invalid.

(In reply to comment #6)
>   var n, data = "";
>   while ((n = iistream.available()) != 0) {
>     data += iistream.read(n);
>   }

Does this work? What if the server doesn't send data for a few seconds, and only
then continues sending? Wouldn't available() return 0 during that time?

Comment 12

[Darin Fisher]

No, available will block until there is data.  The nsIInputStream returned from
nsIChannel::open has blocking semantics.  (The implementation for HTTP actually
calls nsIEventQueue::WaitForEvent and HandleEvent in a loop until data arrives.)