145546 - <embed> type attribute not passed to plugin

Status: VERIFIED INVALID

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Steve Freeland]

Reproducible always, seen on Linux 1.0RC2:
    On the page referred to above (see URL) there's an <embed> tag in it with a
type=audio/x-zipped-mod attribute, *but* when the file is requested the web
server it goes out with an application/octet-stream Content-Type: header.  The
result, when I open  the page using Mozilla, is a Plugger error window which
says that it can't find an appropriate type for application/octet-stream.  So
presumably the HTML "type" attribute is being used to select the plugin, but the
HTTP header is being passed to the plugin when it's instantiated.  I don't know
where the correct behaviour is defined but I'm assuming this inconsistency is a bug.

Comment 1

[R.K.Aa.]

when testing without the MOD plugin installed, i too was prompted do download
the file. After installing the plugin, it simply played the sound.
Testing with current trunk CVS, Linux. (Crossover w/Windows version of MOD plugin)

Reporter: Have you configured plugger with something that can play .mdz files?

Comment 2

[Steve Freeland]

It works with Crossover for me as well, but not Plugger.  I suspect the
dedicated .mod plugin just assumes that whatever data it gets is the correct
type without checking it -- I tested this by creating a page which embeds an
object with "type=audio/x-mod" but with the src attribute pointing to a .png
file.  The .mod plugin tried to load it and just played garbage noise.

Of course this could mean my bug is invalid and the plugin is being passed the
MIME type in the <embed> tag's "type" attribute, but Plugger's behaviour seems
to contradict this.

To answer your question, I'm pretty sure I've got Plugger configured properly --
it wouldn't have registered itself to handle the audio/x-zipped-mod MIME type
otherwise.

Comment 3

[Steve Freeland]

More supporting evidence:  If I go try using Plugger on my test page, and set
the <embed> tag's "src" attribute to point to a .gif file, the error message I
get is "Plugger: No approperiate application for type image/gif found!" 
("approperiate" is not my typo, incidentally)

Here's my test page, if it helps:  http://www.hasc.com/~nephtes/embed1.html

Now using 2002051909 (branch), incidentally, no change in behaviour that I can see.

Comment 4

[rubydoo123]

handing to serge for review

Comment 5

[rubydoo123]

1.2

Comment 6

[Peter Lubczynski]

--->INVALID

We need to pass the HTTP header's mime-type to the plugin rather than the
EMBED's because the plugin needs to know what kind of mime the data will be and
what to do with it. 

Removing the TYPE attribute should cause us to use a plugin as defined by the
HTTP header. This currently has some problems, see bug 157554.

Comment 7

[Steve Freeland]

Hmmmm.  HTML 4.01 seems to agree (this is for <object>, there is no <embed>):

type = content-type [CI]
This attribute specifies the content type for the data specified by data. This
attribute is optional but recommended when data is specified since it allows the
user agent to avoid loading information for unsupported content types. If the
value of this attribute differs from the HTTP Content-Type returned by the
server when the object is retrieved, the HTTP Content-Type takes precedence.

I guess there's no arguing with the spec, but it seems to me that in practice
the "type" attribute is used in exactly the opposite way -- to override the
server's Content-Type: header when it's known not to recognize the file
properly.  (Besides, wouldn't the above make the attribute only relevant at all
when there *isn't* a Content-Type header?)

In any case, this still leaves the issue that the MIME type used to choose the
plugin and the MIME type passed to the chosen plugin are different.  Is this
reasonable, and is this bug still invalid?

Comment 8

[shrirang khanzode]

.