Closed Bug 74374 Opened 19 years ago Closed 16 years ago
Mozilla should use the type attribute of <a> if server returns application/octet-stream
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 ...
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....
Assignee: rickg → neeti
Component: Viewer App → Networking: HTTP
QA Contact: rickg → tever
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.
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Mozilla should use the type attribute of <a> → Mozilla should use the type attribute of <a> if server returns application/octet-stream
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.
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 ...
*** Bug 110431 has been marked as a duplicate of this bug. ***
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)
Target Milestone: mozilla1.0 → mozilla1.0.1
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.
> 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....
> 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).
QA Contact: tever → ian
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).
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.
moving neeti's futured bugs for triaging.
Assignee: neeti → new-network-bugs
*** Bug 185623 has been marked as a duplicate of this bug. ***
-> file handling, as I understand the original bug. If this has morphed via the dispute steming from the relnote, get yourselves a new bug.
Assignee: new-network-bugs → law
Component: Networking: HTTP → File Handling
QA Contact: ian → petersen
INVALID per comments.
Status: NEW → RESOLVED
Closed: 16 years ago
QA Contact: chrispetersen → ian
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.