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.
> 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
