Judson Valeski wrote:
Doug Turner wrote:No, that is wrong. Different imaginable implementation of nsIChannel could return different contents based on read/write positioning. I can imagine a case where two reads from different offsets could return different content types. They definently would return two different content length.Both are attributes that you do not know until you do a read. We have aRegarding moving content-type out to the request. I'm not clear on why it shouldn't be rooted in the nsIChannel either. We have the following structure
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.channel (say, http://www.foo.com/bar.html
|
-------------------------------------------
| |
nsIRequest (from an AsyncRead) nsIRequest (from an AsyncWrite)
the content type of the Read or the Write is always going to be the same. I don't see when it will be different; thus, content-type should be rooted off the channel.
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.
Does this make sense?
