Doug Turner wrote:
>
> Rick Potts wrote:
>
>
>> 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.
But even if the 'content-type' and 'content-length' are not known until
a connection has been established, I still think that they should live
on the channel - because it is our abstraction of the logical connection...
If these attributes move to each individual read/write request, I think
they will still need to be cached within the channel so they can be
propagated from one request to the next...
Take HTTP for example... Is you were to issue more than one AsyncRead
request on the same channel - say several byte-range requests - the
'content-type' and content-length' attributes would have to be
propagated from one request to the next... Otherwise a consumer could
not access the correct values of these attributes regardless of which
request was queried.
However if they remained on the channel, they could be shared among all
of the requests.
I guess that the bottom line is that I think that 'content-type' and
'content-length' are attributes of the connection rather than an
individual read or write request. As such, they should remain in
nsIChannel...
does this make sense?
-- rick
