Both are attributes that you do not know until you do a read. We have aRegarding moving content-type out to the request. I'm not clear on why it shouldn't be rooted in the nsIChannel either. We have the following structure
hack in http which guesses before any transaction, but this is all
wrong. This hack basically uses the MIMEService and guesses based on the
URI's file extension. I hope to move these kind of guessing outside of
the nsIChannel/nsIRequest.
channel (say, http://www.foo.com/bar.html
|
-------------------------------------------
|
|
nsIRequest (from an AsyncRead)
nsIRequest (from an AsyncWrite)
the content type of the Read or the Write is always going to be the same. I don't see when it will be different; thus, content-type should be rooted off the channel.
Regarding the hack in HTTP. Indeed, it is a hack. Ideally the necko consumer would make the content type assumption if HTTP couldn't produce one. (note: that FTP employs the same hack). However, our application flow doesn't permit such elegent design. Protocol channel::GetContentType() is assumed to be the root of content type info; we have too many subsystems that would have to be smart about dealing w/ unknown content types. We've been down this road several times (remembed AsyncOpen() :-)). If you need to prove it to yourself, stub out the hacks and try to use the app. You'll fix a few places where it causes trouble, and you'll get yourself into a bind with a few that you can't fix (chicken... egg.. problem). Note: trying to use the app includes things like loading content from HTTP servers that don't provide a file extension, or a content-type header in the response. it means loading files from disk that contain html tags, but no extension... .html extension but no html content inside, FTP files w/ out file extensions.
Java.net has a whole extra layer between the networking layer and the consumer. They do content type negotiation in this layer. We basically tried to put this layer into SeaMonkey and gave up. It's one thing to architect a content negotiation layer from the ground up, it's another to try and wedge it in after the fact (too many subsystems make too many assumptions about how/when they can count on a static content-type).
Jud
