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.
> 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."
> 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?
> 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.
Jud
