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.You've pulled the default mime type from the JS handler. I don't know the JS handler at all, but I'm concerned that consumers are going to get ahold of a channel/request before the type has been set, and that this will wreak havoc. Do JS loads happen via the uriLoader? If so, are you assuming (probably correctly) that the unknowndecoder will resolve the type to text/html?As you know, the branch is not finished yet and has not been reviewed. Setting the content type of a channel that you do not implement is a edge case. I still need to fix the uriloader to deal with this.
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: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?http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHTTPChannel.cpp#411
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.
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!
Jud
