• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Download firefox problem

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    Download firefox problem

    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.
    bloggoth

    If everything isn't black and white, I say, 'Why the hell not?'
    John Wayne (My guru, not to be confused with my beloved prophet Jeremy Clarkson)

    #2
    Originally posted by xoggoth View Post
    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/
    <Insert idea here> will never be adopted because the politicians are in the pockets of the banks!

    Comment


      #3
      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.
      bloggoth

      If everything isn't black and white, I say, 'Why the hell not?'
      John Wayne (My guru, not to be confused with my beloved prophet Jeremy Clarkson)

      Comment


        #4
        Originally posted by xoggoth View Post
        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...
        Behold the warranty -- the bold print giveth and the fine print taketh away.

        Comment


          #5
          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!
          bloggoth

          If everything isn't black and white, I say, 'Why the hell not?'
          John Wayne (My guru, not to be confused with my beloved prophet Jeremy Clarkson)

          Comment


            #6
            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.
            <Insert idea here> will never be adopted because the politicians are in the pockets of the banks!

            Comment


              #7
              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.
              bloggoth

              If everything isn't black and white, I say, 'Why the hell not?'
              John Wayne (My guru, not to be confused with my beloved prophet Jeremy Clarkson)

              Comment


                #8
                Originally posted by Sysman View Post
                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

                Comment


                  #9
                  x-xoggoth-slime-descriptor
                  How long before that becomes a standard?
                  bloggoth

                  If everything isn't black and white, I say, 'Why the hell not?'
                  John Wayne (My guru, not to be confused with my beloved prophet Jeremy Clarkson)

                  Comment


                    #10
                    Originally posted by NickFitz View Post
                    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?
                    Behold the warranty -- the bold print giveth and the fine print taketh away.

                    Comment

                    Working...
                    X