74374 - Mozilla should use the type attribute of <a> if server returns application/octet-stream

Status: RESOLVED INVALID

(Core Graveyard :: File Handling, defect)

Description

[Tobias Burnus]

This is with Mozilla 0.8.1. I use a link to a PDF file (foo.pdf) and give as 
type of this link "application/pdf". If I click this link I get the application 
dialog with "application/octet-stream".

Note that this may only apply to the offline version since the server can also 
send such information. The usage of type="" should overwrite the settings of 
the server though (which are purely based on extention) since e.g. .rpm is both 
RealPlayer and RedHat Package Manager ...

Comment 1

[Boris Zbarsky [:bzbarsky]]

Actually, no.  The server should override the type= attribute.  From
http://www.w3.org/TR/html4/struct/links.html#h-12.2:

type = content-type [CI]
  This attribute gives an advisory hint as to the content type of the content
  available at the link target address. It allows user agents to opt to use a
  fallback mechanism rather than fetch the content if they are advised that they
  will get content in a content type they do not support.Authors who use this
  attribute take responsibility to manage the risk that it may become
  inconsistent with the content available at the link target address.

Note the "advisory hint" part and the recommended use of the type attribute by
user agents....  The type= attribute is not the last word on the type by any means.

It is presumed that the server always returns the correct content-type. The
server does not _have_ to use extension for the content type, even though many
servers do.

This looks invalid to me....

Comment 2

[Tobias Burnus]

Given the comments from Boris Zbarsky I would like to change it to:
a) Use the file extention (there is bug for this)
if this doen't exist use
b) The type=""
this is overwritten by
c) The type given by the server
(but only if this is *not* application/octet-stream)

This bug is only about (b) and therefore applys mostly to FTP, Gopher (?) and 
local file systems but also to server types of the type "application/octet-
stream" since the given type is usually better.

Comment 3

[Boris Zbarsky [:bzbarsky]]

setting status to NEW.  Proper thing to do would seem to be:

1)  Use the HTTP content-type
2)  If it does not exist or is application/octet-stream use the type="" 
    attribute
3)  If this also does not exist, fall back on extension-guessing.

changing summary accordingly.  Should the severity be enhancement?

Comment 4

[Akkana Peck]

That's a bummer (what Boris quoted from the W3C).  I have this problem, too,
where I have a file on my site of type .prc, which the server doesn't recognize,
and the server maps it to text/plain so there's no way to get mozilla to handle
it properly.  I see this problem on a lot of other people's pages, too, where I
click on a link and mozilla slowly loads a huge binary file as text/plain in the
main window.

It would be rock if mozilla had a way to handle these files.

Comment 5

[Akkana Peck]

Turns out Apache users have an alternative: create a .htaccess file which has a
line like:
AddType application/octet-stream .ext
for whatever extensions and types they need.  No root access needed.  Dunno if
other servers are as easy ...

Comment 6

[Akkana Peck]

Doc on that: http://httpd.apache.org/docs-2.0/mod/mod_mime.html#addtype

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 9

[Niklas Dougherty]

From the release notes of 0.9.7:

"    * When a page using a strict document type declaration (e.g. HTML 4.01
Strict) links to an external style sheet (using <link>, @import, etc) Mozilla
will only load the style sheet if it is served with a MIME type of "text/css".
Style sheets served with other MIME types, like text/plain,
application/x-pointplus, etc. will not be loaded. To add the proper css mime
type to an Apache web servers, add "text/css css" to the system mime.types file.
Or if you can't do that, add "AddType text/css .css" to your .htaccess file."


1) 99.9% of all web developers have no way to fix a lousy server. They can only
influence the output by the type attribute in http-equiv, link and similar. You
just took away this possibility.

2) Who said my ISP uses Apache? They don't. They use Netscape.

3) A CSS file doesn't have to have a file suffix on other platforms than
Micro$ux Win-DOS. You just gave in for an extremely lousy way to store metadata.

Mozilla just went into the trash. I really don't care anymore. You guys simply
don't understand the perspective of the simple developer, who is not the
sysadmin of a major ISP.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> 99.9% of all web developers have no way to fix a lousy server.

Then their page should arguably not be in standards mode, since it is in fact 
_not_ standards compliant.  In quirks mode we continue with the old (broken per 
the HTTP and HTML specs) behavior.

Also notice that (at least for Apache) the .htaccess method does _not_ require 
administrator access to the web server and should Just Work on most server 
setups.  The release note can be expected to include similar mechanisms for 
other servers if such exist.

> Who said my ISP uses Apache?

Absolutely no one, nor was this implied.  Every single bug filed so far about 
the issue was on apache web servers because some versions of apache have .css 
files mapped to application/x-pointplus.  The release note aimed to provide 
enough information so people would not be completely confused, while at the same 
time providing a way to fix pages in the vast majority of the cases so far 
encountered.

> A CSS file doesn't have to have a file suffix on other platforms than
> Micro$ux Win-DOS.

Correct, but that seems irrelevant to me.  If your platform of choice has 
a different method of identifying file types, then presumably the web server for 
your platform supports that method.  If it does not, this is a bug in the web 
server, not in the client.  The client merely uses the type provided by the 
server.

The release note does not really mention extensions except in the context of 
Apache.  Most Apache installations are on Unix, and on most Unices there is no 
way of associating type metadata with a particular file (unlike, say, on MacOS 
or BeOS).  As a result, Apache uses extensions to get type metadata on such 
systems.  There are other ways to configure the file-to-type mapping.  Again, 
the release note just tries to solve the problem in the most common case, and in 
that case the file _is_ named with a .css extension.

> You guys simply don't understand the perspective of the simple developer

Yes, we do.  Hence the existence of quirks mode in which we violate all sorts of 
standards to work with existing broken web pages.

I'm sorry that you find the HTTP standard on the handling of Content-Type 
headers inconvenient. It really would be nicer to get rid of this pesky header 
altogether and push all type recognition to the client, leaving the server to 
more important work, would it not?  This way the client, which has much less 
information than the server about the file's metadata (since it just has access 
to the file contents and file size and _maybe_ the filename) can do the best job 
it can of guessing....

Comment 11

[Niklas Dougherty]

"This way the client, which has much less information than the server about the
file's metadata (since it just has access to the file contents and file size and
_maybe_ the filename) can do the best job it can of guessing...."

Your "client" is given the following information in a page (within <>, dunno if
they are rendered here):

meta http-equiv="Content-Script-Type" content="text/javascript"
meta http-equiv="Content-Style-Type" content="text/css
meta http-equiv="Content-Type" content="text/html; charset=utf-8
link rel="stylesheet" href="css"

Yet the client has to ask the server if this is correct. Your client ignores the
instructions of the developer. This is what this particular bug is all about (if
attribute type is used with element A), and now it is *extended* instead of
remedied.

A server is just a dumb machine. There may be more intelligence to be found in a
page (or at least its author). Yet Mozilla will trust the server, regardless of
what the page says about types used. Standard or not, it is plain stupid. It
takes the power away from the developer and gives it to the server.

Why not just remove type specing altogether from the Strict standard, since it
is just a "recommendation", overridden by the omnipotent server?

The *intelligent* way to do this is to trust the user (developer) and not even
query the server if a type is given. Especially in strict mode, since the
stricter it is, the more knowledgable a user (developer) is.

The HTML standard has the following information regarding this, and if there is
a conflict with the HTTP standard, the HTTP standard should be ignored, since it
is low-level, dumb-ass brain dead server stuff anyway:

http://www.w3.org/TR/html4/present/styles.html#default-style

---
14.2.1 Setting the default style sheet language

Authors must specify the style sheet language of style information associated
with an HTML document.

Authors should use the META element to set the default style sheet language for
a document. For example, to set the default to CSS, authors should put the
following declaration in the HEAD of their documents:

<META http-equiv="Content-Style-Type" content="text/css">

The default style sheet language may also be set with HTTP headers. The above
META declaration is equivalent to the HTTP header:

Content-Style-Type: text/css

User agents should determine the default style sheet language for a document
according to the following steps (highest to lowest priority):

   1. If any META declarations specify the "Content-Style-Type", the last one in
the character stream determines the default style sheet language.
   2. Otherwise, if any HTTP headers specify the "Content-Style-Type", the last
one in the character stream determines the default style sheet language.
   3. Otherwise, the default style sheet language is "text/css".

Documents that include elements that set the style attribute but which don't
define a default style sheet language are incorrect. Authoring tools should
generate default style sheet language information (typically a META declaration)
so that user agents do not have to rely on a default of "text/css".
---

Comment 12

[Boris Zbarsky [:bzbarsky]]

> Why not just remove type specing altogether from the Strict standard

Because the type tells the browser whether to even _bother_ contacting the web 
server. Note that this same standard also says that any conflicts between the 
server and the type attribute are the fault of the web author.

If I recall correctly, all the Content-*-Type headers you mention apply to CSS 
and scripts embedded in the document via <script> and <style> tags or via inline 
style or event handlers (for scripts).  Not sure about this, though; setting QA 
to Ian who should know.

> specially in strict mode, since the stricter it is, the more knowledgable a
> user (developer) is.

The intent of the mode is not to be "strict" but to be "standards compliant".  
What you suggest is a gross violation of the standards (with the above caveat 
about meta tags and my insufficient knowledge thereof).

Comment 13

[Niklas Dougherty]

http://www.w3.org/TR/html4/struct/links.html#adef-type-A

type = content-type [CI]
This attribute gives an advisory hint as to the content type of the content
available at the link target address. It ALLOWS USER AGENTS to opt to use a
fallback mechanism rather than fetch the content if they are advised that they
will get content in a content type they do not support.
Authors who use this attribute take responsibility to manage the risk that it
may become inconsistent with the content available at the link target address.
For the current list of registered content types, please consult [MIMETYPES].
---

The same holds for "LINK type".

See http://www.w3.org/TR/html4/struct/global.html#adef-http-equiv for HTTP headers.


The standard lets you (Mozilla, the user agent) choose if you want to give the
power to the user or the server. You have chosen to empower the server. This is
a choice, not a mandatory requirement.

So, the problem for a developer is now to find an ISP that runs a smart web
server that doesn't require Windows style metadata by filename extensions. The
default Apache configuration doesn't use magic numbers for determining the
content type of a file ( i just tested this).

Comment 14

[Boris Zbarsky [:bzbarsky]]

Let's not have selective quoting here.  The spec says:

"allows user agents to opt to use a fallback mechanism rather than fetch the 
content".  So the two options are:  1) Fetch the content and handle it normally 
or 2) not fetch the content and do something else.  All the type attribute does 
is let you pick between those two.

The HTTP specification is very clear about what happens in case #1.

> default Apache configuration doesn't use magic numbers 

Yeah... the option is there but off by default, iirc.  At least in older 
versions of Apache; I have not tested the newest ones.

You have a valid point, which is that HTML _should_ maybe provide a way to 
override the HTTP type header.  At the moment it does not, as far as I (and 
others) can tell.  This is a problem with the spec, however, not with 
implementations.  Lobbying browser makers to "fix" this by breaking the spec 
seems pointless to me; it would be much more effective to lobby for changes to 
the spec.

Comment 15

[Doug Turner (:dougt)]

moving neeti's futured bugs for triaging.

Comment 16

[Christopher Hoess (gone)]

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

Comment 17

[benc]

-> file handling, as I understand the original bug.

If this has morphed via the dispute steming from the relnote, get yourselves a
new bug.

Comment 18

[Hixie (not reading bugmail)]

INVALID per comments.