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
would almost like to see content-type and content-length added as
parameters to OnStartRequest... but this is bad for other reasons (1. no
parallel idiom for sync i/o, and 2. no way to get this info later on).
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. If the consumer does not have an open
request/stream, then the best they can do is talk to the MIME service.
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.
>
>> If you ask for the content type for it is is know, it is going to hand
>> you back an error that says
>> "I don't know". Or maybe it should just return unknown. This point has
>> not been discussed.
>
>
> Currently, if you channel->GetContentType(), you'll always get "something"
> back. You won't error out. Worst case, you get an "unknown" string, which
> the uriloader takes action on by passing the stream into the unknown decoder
> for byte scanning.
>
>> In the cases I changed, this was not an issue since the channel was not
>> opened (eg no request was made)
>
>
> I hear you, but how would I know that as a consumer (you knew that by
> studying the code. the semantics should be describable in a doc)? How would
> I know if the connection had been made or not?
>
> Jud
>
