Currently, HTTP is caching a reference to the mime-service via CLSID. This is causing it to pick up the "obsolete" mime-service in netwerk\mime. Not the "correct" mime-service in uriloader/exthandler. This is causing problems when a response does NOT include a content-type and the data is of a type which a plugin can handle. In this situation, the URI loader incorrectly hands the URI off to the helper-app service bypassing plugins which can handle the content-type. In a related issue, HTTP needs to treat a server content-type response of "*/*" as 'unknown-content-type'... "*/*" as NO meaningful content-type information. -- rick P.S. This bug is related to bug #120113
Created attachment 65458 [details] [diff] [review] Removes the old mimeservice registration and fixes HTTP to deal with "*/*" as if it were application-x-unknown content type...
right now, the way that the mime-service is divided between netwerk/mime and uriloader/exthandler seems strange. It seems like a cleaner solution is to create an 'extensible mime-service' in netwerk/mime that deals with a set of dynamic 'content-type providers' which are registered at runtime... This allows the URILoader to augment the core mime-service with knowledge of plugin and helper-app content-types without *actually* implementing the mime-service itself... It also allows necko to have access to a mime-service *even if* the URILoader is not available (for example in a standalone necko application...). thoughts?, comments? -- rick
i totally agree... eliminating the built in mime service all together seems bad because necko as a standalone library is one of our future goals. however, we are trying to build a web browser first and foremost, so perhaps we should land your patch (which looks good by the way, sr=darin), and just file a follow up bug to clean things up. it's up to you... if you wanna go the whole nine now, that'd be great too ;-)
Comment on attachment 65458 [details] [diff] [review] Removes the old mimeservice registration and fixes HTTP to deal with "*/*" as if it were application-x-unknown content type... r=mscott
Attachment #65458 - Flags: review+
patch checked in.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
shouldn't we stop compiling (and actually cvs remove) the old service?
For removing the old stuff, see bug 101017, P4, Future (originally filed because both mimeservices use the same contractid...)
since necko depends on the mime service shouldn't it include at least a bare bones implementation? without it, it'd be more difficult to distribute necko as a standalong library. not that we are anywhere close to being able to package necko by itself, but it is one of our future goals.
Good, glad to see that some movement is finally occuring here. So, I downloaded the nightly build this morning (1/28), installed on Windows ME, installed our SwiftView plugin (via Internet Explorer, since there still is no Smart-Update installation support), copied the npsview.dll to the Mozilla plugins directory (since we haven't added Mozilla/NS 6 to our installer since they don't work yet), and find that: Good: - there is now a help about plugins (wonderful!) - and refresh shows our plugin correctly. Just to be sure, I restarted Mozilla, and: - typing a path to a file in the address bar correctly starts and runs our plugin. Failed: - typing a URL to a file of our plugin's suffix in the address bar, or clicking on a file: or http: url on a web page try to run the Windows application registered for the suffix instead of the plugin. - an EMBED of a SwiftView-suffix file starts our plugin, but it's unable to display the file in the page. It only works in a mode we support that displays the file in an external window. This we could investigate further, perhaps find a workaround on our end...but it has always worked fine in NS 4.x...and has been broken this way in Mozilla since at least Feb 2001. So unless that build didn't get this fix, there is still more work to be done on MIME ->plugin mapping...plus the other issues... So - don't close bug 43556 yet - and maybe not this one either... SwiftView plugin can be downloaded with NS 4.x from www.swiftview.com.
*** Bug 122024 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.