Doug Turner wrote:
>
>
> Judson Valeski wrote:
>
> Doug Turner wrote:
>
> 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.
>
> Regarding 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
>
> 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.
>
> 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.
>
For the content-type, moving it from nsIChannel to nsIRequest will *not*
solve the problem of the ficticious protocol which returns URIs where
different byte-ranges contain data of different content-types...
Assuming that the content-type is part of the request, what happens if a
given request spans multiple coontent-types? ie. bytes 1-10 have
content-type/x and bytes 11-20 have content-type/y. If the consumer
issues a single AsyncRead of 20 bytes, the data will have multiple
content-types... Having the content-type hang off of the request does
not solve this problem!
As far as I know, the content-length refers to the total amount of data
available for a given URI... So, issuing multiple byte-range request
will involve different offsets, but should still refer to the same
content-length.
The whole point of byte-range requests is to read a particular part of
the content associated with a URI. If you can't know how much data
there is before you read, and you can't assume that the total amount of
data will be the same from one read to the next (ignoring the issues of
caching) then how can you make use of byte-ranges?
> 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?
As far as I know, for all of the protocols that we support, the
content-type and content-length are available once a connection has been
established with the server (ie. protocol negotiation has completed)...
Then, it remains the same for all requests issued through that channel.
I agree that for some protocols, the content-type and content-length are
not known before the connection has been established, but I don't see
this as an arguement for moving them into each request...
-- rick
