>> No, that is wrong. Different imaginable implementation of nsIChannel
>> could return different contents based on read/write positioning.
>
> Hmm, ok. This rocks my world then. Necko's channel/callback design was
> born out of the idea that there was one content type per channel, and
> that a channel ultimately represented a "connection" to a single URI.
> You're turning that on it's head.
I have already made all the changes on my branch and either it was a
trival change or the code was doing the wrong thing in the first place
(eg. depending on the content type on the channel before any request was
made)
>> Content type and length is part of the information that you get from
>> a request. Anything before that is a guess. There are too many
>> places in the code right now that do the wrong thing wrt creating
>> channels vs. opening them. Making content information only
>> available after the request is the right thing to do.
>
> You won't get this far without months of effort. We've tried before (3
> times).
I have not tried. :-)
