Rick Potts wrote:
> OK.. I see now... You need access to the nsIStreamContentInfo
> interface which is part of the request object returned by
> AsyncRead(...) not the channel itself... Is this correct?
>
yes.
> I guess, now I'm wondering why nsIStreamContentInfo is part of the
> request being returned, rather than being on the channel itself. I
> guess that I'm assuming that for a given channel, the content-type and
> content-length are fixed, regardless of how much of the data you
> actually read... How could these values ever change for a given
> channel?
>
> I can see how the transferCount and transferOffset attributes of the
> channel should be moved into the request, but not the content-type and
> content-length attributes since they are supplied by the server for a
> given URL...
>
> what am I missing?
Both are attributes that you do not know until you do a read. We have a
hack in http which guesses before any transaction, but this is all
wrong. This hack basically uses the MIMEService and guesses based on the
URI's file extension. I hope to move these kind of guessing outside of
the nsIChannel/nsIRequest.
