Judson Valeski wrote:
> Darin Fisher wrote:
>
>> Judson Valeski wrote:
>>
>>> Doug Turner wrote:
>>>
>>>> I will see about passing that in the constructor or having an accessor
>>>> specific to streamIOChannels.
>>>
>>>
>>> not a bad idea.
>>>
>>>>>> In every case, the server has not been opened yet! :-/ Which
>>>>>> means that the mime service is going to be called. Yes, that is
>>>>>> right, the http protocol is doing the same thing today:
>>>>>>
>>>>>> http://lxr.mozilla.org/seamonkey/source/netwerk/protoco
>>>>>> /http/src/nsHTTPChannel.cpp#411
>>>>>
>>>>> good point. I didn't look enough context. obviously if this were done
>>>>> *after* a connection, it would be bad; and defining when it's ok to
>>>>> use the content type info in your changes is the challenge. I get a
>>>>> nsIRequest right after I call AsyncRead|Write; what if I want to get
>>>>> content info right then (before the server connection)? How do I know
>>>>> when the server has connected? If I know when it's connected only when
>>>>> I get an OnStart(), then how do you protect against me calling
>>>>> info->GetContentType() *before* then; documentation?
>>>>
>>>> Well, that is up to the protocols right?
>>>
>>>
>>> No. This is a constraint on the architecture. Each protocol has to implement
>>> certain semantics. We cannot interject inconsistencies between protocols
>>> which allow one protocol to return final content type info at pointA, and
>>> another to return final content type info at pointB. Consumers need more
>>> definition than that. For example, the uriLoader has no idea what protocols
>>> it's loading, it just loads channels. if one channel impl behaves
>>> differently than another, the uriloader breaks down.
>>
>> The content-type must be set by the time OnStartRequest is fired. This
>> is both reasonable and easily justified by the fact that OnDataAvailable
>> would have little meaning if the content-type were not know a'priori.
>
>
> I totally agree. However, I believe there are places in teh system where we query
> for content type *before* OnStart has been fired; thus my concern.
No problem...
>
>> I like the idea of content info being QI'able from nsIRequest in the
>> Async case (and from nsIInputStream in the Sync case). This tells
>> consumers that they need to have an open request/stream in order to
>> query the content info.
>
>
> There are stream listener type consumers (the one's getting the data), and there
> are channel consumers (folks who just hold ref to a channel). The latter has no
> concept of whether or not a request/stream/channel has been "opened."
These folks are mis-using nsIChannel. See below.
>
>> If the consumer does not have an open
>> request/stream, then the best they can do is talk to the MIME service.
>
>
> how do they know if it's "open" or not?
If they have a nsIRequest, and OnStartRequest has fired, then they know
they can query the content-type, etc. Otherwise, they must use the MIME
service. It is wrong to create channels just for the purpose of MIME
type resolution.
>
>> Having a channel is not enough to identify a request/stream... you have
>> to have a nsIRequest (or an nsIInputStream). A channel is little more
>> than a "requestor" ... it provides methods for establishing a request
>> for the content identified by the channel's URI attribute. Before a
>> request is opened, a channel can in general do little more than guess at
>> what the content info will be.
>
>
> yup.
Then it is clear. Consumers must talk to the MIME service if they do
not have an "open/completed" request to query.
Darin
