> I know it's not done. agreed. but removing that default type will
> likely wreak (sp) havoc on someone somewhere. I believe
> streamIOChannel's require that you set the content type if you want
> anything in there other than unknown-type.
I will see about passing that in the constructor or having an accessor
specific to streamIOChannels.
>> 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? 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.
>> It is wrong to have this hidden via the protocol.
>
> hmm, given the mime type ordering precidence I pointed out before
> (server comes first, then file extension mapping), we're at least able
> to enforce that if the mime service usage is buried in the protocol
> itself. As a consumer, how do I know when/if I'm supposed to use the
> mime service to get the mime type? What if I get the mime type
> mapping, and I ignore what the server said (breaks precidence); that
> would be bad.
>
In the cases I changed, this was not an issue since the channel was not
opened (eg no request was made)
>
> I agree that hiding this is wrong, but given all the consumers out
> there, I'm worried adding this inference will cause trouble. All we
> need is one more person to load a URI, and for them not to understand
> these semantics and bad things happen. Of course, if you can insert
> this layer, and document the semantics for future users, great!
>
I agree with you here. HTTP might just have to call into the MIME
service. I will leave this question with Darin.
