120590 - HTTP should NOT use the "old" mime-service.

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[rpotts (gone)]

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

Comment 1

[rpotts (gone)]

Attachment: Removes the old mimeservice registration and fixes HTTP to deal with "*/*" as if it were application-x-unknown content type...

Comment 2

[rpotts (gone)]

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

Comment 3

[Darin Fisher]

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 4

[Scott MacGregor]

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

Comment 5

[rpotts (gone)]

patch checked in.

Comment 6

[Judson Valeski]

shouldn't we stop compiling (and actually cvs remove) the old service?

Comment 7

[Bradley Baetz (:bbaetz)]

For removing the old stuff, see bug 101017, P4, Future (originally filed because
both mimeservices use the same contractid...)

Comment 8

[Darin Fisher]

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.

Comment 9

[Glenn Widener]

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.

Comment 10

[Mike Kaply [:mkaply]]

*** Bug 122024 has been marked as a duplicate of this bug. ***