110431 - Attribute "type" for HTML element "A" should override server content type

Status: VERIFIED DUPLICATE of bug 74374

(Core Graveyard :: File Handling, defect)

Description

[Niklas Dougherty]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.5) Gecko/20011015
BuildID:    2001101516

Constructs such as:

<A href="../qt/mov/animation" type="image/x-quicktime">Stillbildsanimering</A>

will render binary garble rather than loading the Quicktime plugin.


Reproducible: Always
Steps to Reproduce:
1.Load http://homepage.mac.com/nikd/map/
2.Find "Stillbildsanimering"
3.Click that link

Actual Results:  Binary garble is shown, that is, the raw contents of the
Quicktime movie.

Expected Results:  The Quicktime plugin should load and render the contents,
according to the HTML 4.01 strict spec.


The false type "image/x-quicktime" is used to prevent type hijacking (it is
really "video/quicktime" in the data); it is exclusive for Quicktime. The
browser should just pass the data at any rate, as long as the type is
registered. No need to be confused about this one.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Actually, there is a problem here. The "type" attribute is an advisory type. 
That spec says that it should be used for deciding whether to fetch the content
at all.  What should be done with the content once it's fetched is determined by
the type returned by the server. 

The server sends text/plain for this file. 

This is possibly duplicate the bug asking that we use that type attribute as a
last-ditch fallback in case the server sends no type at all (can't find the bug
number at the moment).

Comment 2

[Boris Zbarsky [:bzbarsky]]

And in any case, this would be file handling.

Comment 3

[Greg K.]

Or this could be Evangelism since QuickTime content should *never* be served as
text/plain.

Comment 4

[Niklas Dougherty]

The evangelism doesn't consist so much in Quicktime as in separation of metadata
from real data, i.e. moving away from Microsofty DOS extensions. The movie is
named "animation" without the usual extension ".mov". If you look carefully,
*all* items on that particular page, and most other pages at the same site, do
not have extensions. So how does Mozilla normally distinguish a png from a jpeg
or a gif if the server sends text/plain for extensionless items? They *are*
rendered, after all! Well, it relies on the IMG tag and reads the first line
(although I doubt it knows how to render qtif and tiff).

Now, consider http://homepage.mac.com/nikd/poptops/The images you see are
extensionless and are of types png, jpeg and gif, although this is not specified
anywhere (although the IMG tag states it is an image). It is specified, however,
in the <A href> part, but clicking on a link next to an image yields binary
garble rather than a jpeg image.

This is inconsistent with how Mozilla treats other files inline. And it is not
very helpful to users. I hate to bring it up, but Explorer does consider the
type and renders stuff correctly.

Comment 5

[Boris Zbarsky [:bzbarsky]]

So the request is to treat type="something" on <a> in the same way as we treat
the existence of <img>?  Setting status to NEW.  Put that way it sounds pretty
reasonable.  :)

Oh, and does IE _really_ look at the type attribute?  Or does it just sniff the
content stream and ignore the server-provided type?  The latter is something
Mozilla should not, and I hope will not ever, do.

One other point (about evangelism).  The _server_ is where the metadata/content
separation should really take place, since the server has _much_ more
information about a file than a browser does.  Depending on the operating
system, the OS itself may prfovide accurate metadata for a file to the server. 
And any server worth its salt will do magic number lookups, allow you do specify
that all files in a given directory are of a given type, and so forth.  The
letter of the HTTP spec requires the browser to use the server type without any
quibbles.  Yes, we break that with <img>, but this does not make broken servers
like the one you point to any more correct.

Comment 6

[Boris Zbarsky [:bzbarsky]]

*** This bug has been marked as a duplicate of 74374 ***

Comment 7

[sairuh (rarely reading bugmail)]

v