I'm working on a modified version of the old Mozilla ForceContentType tool as a Firefox 1.0 extension, and I've run into a bit of a problem. Everything seems in place now, minus some minor, fixable bugs, but nsIHttpChannel doesn't seem to be doing what it's supposed to.
The behavior of setting the contentType variable of nsIChannel interface during an http-on-examine-response channel notification seems improper (or rather, unpredictable). For certain original MIME types and/or URLs, this technique works fine. I seem to be able to take most text/html URLs and change the content type that FF sees to anything I want, but am unable to get Firefox to see a text/plain page as anything other than text/plain. I have gone back and re-read the documentation of this property, and what I am doing ought to work (I believe), since the documentation says only the following about setting it: Quote from documentation: Setting contentType before the channel has been opened provides a hint to the channel as to what the MIME type is. The channel may ignore this hint in deciding on the actual MIME type that it will report. Setting contentType after onStartRequest has been fired or after open() is called will override the type determined by the channel. Setting contentType between the time that asyncOpen() is called and the time when onStartRequest is fired has undefined behavior at this time. I am not sure about terminology here or about all the details of channel lifecycle (when open is called, when onStartRequest is called), but common sense tells me that I should be in the clear by the time the http-on-examine-response events are triggered. I would think. Unless this is somehow too late in the channel lifecycle to change the content type? You can see a thread I started to no avail asking this question over on the MozillaZine forums at: http://forums.mozillazine.org/viewtopic.php?t=175399 which has a bit more information, code snippets, and links to my draft extension. When I call visitResponseHeaders(this); right after the setting of the content-type value, it doesn't show any changes, so obviously something has to happen to update the headers inside the channel object itself. I even started looking at the nsHttpChannel.cpp source code and tried to understand what actually happens when this value is set - it sets the value in the nsHttpResponseHead object, which happens successfully, but obviously that value gets overwritten or overruled sometime before the page is rendered. I cannot call the channel object's setResponseHeader method to change content-type, since I can see in the C++ source, it explicitly disallows this (which is why I get a Javascript error when I try to do it that way). Does anybody have any ideas what could be going wrong here? The problem is even more frustrating because of my code's partially working status. I'm guessing has something to do with the order of operations on the HTTP channel object, and the state it's in when I get to it, and what happens to it after I change the content type field. Any help or advice would be greatly appreciated. Sincerely, Raefer Gabriel _______________________________________________ Mozilla-netlib mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-netlib
