Download firefox problem

[Sysman]

It looks like the ISP has fixed it now, because I couldn't reproduce the problem.

However I have stuck the following into .htaccess, just in case:

AddType text/plain .txt

[xoggoth]

Could you enforce text by opposite of my problem, prefix with x0D or some other recognisable text? If it's text then odd extra byte at the front hardly matters.

[Sysman]

Afraid not

If they aren't static text files and you have access to the code that serves them, you could pass a type in the query string. Another possibility (on Apache) would be modifying the server config on a per-directory per-filetype basis to set the content type, maybe using a .htaccess file.

They are static text files and the HTML is static too. No PHP or CGI involved and it's wicked fast :-)

,htaccess looks promising. Thanks.

[NickFitz]

My problem could be a misconfigured server then. The shared hosting site I noticed this on recently fixed the Content-Type header setting for downloading log files (*.txt) via the Control Panel. I wonder if they accidentally broke plain text files while they were at it.

Is there a magic incantation I can throw into the HTML which references these text files to set the mime type from there?

Afraid not

If they aren't static text files and you have access to the code that serves them, you could pass a type in the query string. Another possibility (on Apache) would be modifying the server config on a per-directory per-filetype basis to set the content type, maybe using a .htaccess file.

[Sysman]

There's a pretty detailed explanation in the MSDN library: MIME Type Detection in Internet Explorer. I believe FF's content type sniffing follows similar lines (it's documented somewhere on http://developer.mozilla.org/).

If you can find a suitable known MIME type and configure the server to send it as the Content-Type header it should circumvent such problems. In other words, if there is something more specific than "text/plain" or "application/octet-stream" and it's correct for your content, use it.

My problem could be a misconfigured server then. The shared hosting site I noticed this on recently fixed the Content-Type header setting for downloading log files (*.txt) via the Control Panel. I wonder if they accidentally broke plain text files while they were at it.

Is there a magic incantation I can throw into the HTML which references these text files to set the mime type from there?

[xoggoth]

x-xoggoth-slime-descriptor

How long before that becomes a standard?

[NickFitz]

I've recently found FF deciding to interpret straight text files as all manner of things, depending on what it finds in the first few bytes of each file. No other browsers suffer from that. I suspect they are trying to be too clever. Maybe I should be stuffing some file type info into the URL for those text files, I dunno...

In fact all browsers do that, following a lead set by Internet Explorer 4 which had the effect of allowing misconfigured servers to get away with it.

There's a pretty detailed explanation in the MSDN library: MIME Type Detection in Internet Explorer. I believe FF's content type sniffing follows similar lines (it's documented somewhere on http://developer.mozilla.org/).

If you can find a suitable known MIME type and configure the server to send it as the Content-Type header it should circumvent such problems. In other words, if there is something more specific than "text/plain" or "application/octet-stream" and it's correct for your content, use it.

If no known and appropriate MIME type exists then create your own meaningful one, prefixed with "x-" (e.g. "x-xoggoth-slime-descriptor") as the browsers will then assume you know what you're up to and leave your stuff alone

[xoggoth]

Cheers. I didn't, but worth noting. Pity IE isn't the only browser, we could get away with anything because it actually applied common sense.. It even ignored wrong capitalisation like Width instead of width until they decided to get all anal about it. Standards were an unecessary invention of Stalin.

[petergriffin]

PHP: header - Manual

// Just a quick note to this header() function *today*, as of 2011-10-13:
// Latest Firefox (7.01) suddenly will *NOT* let users download file WHEN there is some extra character after the Content-type header !! So be CAREFUL!

// for example: ";" and space... like this:

header("Content-type: application/octet-stream; ");

// THIS IS NO LONGER OPERATIONAL in Firefox 7.01! Be warned! - some pages STOPPED working - in terms of letting download attachments / files !
(in Firefox 6.02 it works, in IE8 and others it also still works... but it may change in the future!)

Check if you have this extra space in your php script.

[xoggoth]

Thanks sysman. Got an answer on another forum. If the PHP script has any whitespace after the ?> it gets sent as part of the file. The script should end with exit; and have no ?>. It's validating ok now. Hurrah!

But the same bloke also pointed out a security problem with my script! Bah!

[Sysman]

Stupid FF is tacking a x0A byte onto the end of the file downloaded via php. I would assume validation would include a length check. Why it is doing this when other browsers don't I have no idea.

x0A is a line feed, i.e. a record terminator. Is FF somehow thinking it's a text file? An executable image file should be replicated byte for byte.

I've recently found FF deciding to interpret straight text files as all manner of things, depending on what it finds in the first few bytes of each file. No other browsers suffer from that. I suspect they are trying to be too clever. Maybe I should be stuffing some file type info into the URL for those text files, I dunno...

[xoggoth]

Cheers. The problem occurs however it is run and if the exe is saved to disc and then clicked. (Programs downloaded from the net get tagged apparently.)

If I do a direct download by clicking a link the digital signature is reported as ok but obviously I can't provide downloads that way or anyone could get them free. It is only if I download indirectly via PHP using headers that FF reports the signature as not valid. Properties shows the signatures are exactly the same.

Stupid FF is tacking a x0A byte onto the end of the file downloaded via php. I would assume validation would include a length check. Why it is doing this when other browsers don't I have no idea.

[petergriffin]

how can the downloaded exe on the hard disc be different depending on browser used?

The web server might be configured to perform some browser sniffing.

Do you right-click and "save link as" or just click on it? Try both methods. There's also an extension to confuse the web server:
https://addons.mozilla.org/en-US/fir...gent-switcher/

[xoggoth]

Sorted the program signing and now I can download my programs ok in IE, Opera, Chrome and Safari. Allthough there is a warning about the program not often being downloaded the certificate works ok and shows my company details.

I just have a problem with bloody Firefox that says the download is unsigned and may damage your computer. The really wierd thing is, I get "unknown publisher" when I double click the exe file on my hard disc that was downloaded using Firefox. The file is also 1byte different in size from the same file downloaded using other browsers!

I can understand different security reports when you click run in the browser but how can the downloaded exe on the hard disc be different depending on browser used? Anyone got any bright ideas? Totally baffled at mo.

PS I have checked the obvious possibility, that it is downloading an old unsigned version from somewhere else due to page caching. I not only refreshed every page but checked the website to ensure there are no old versions and also repeated with 3 programs that were never uploaded in unsigned form.