I..... I got nothing.



  •  I really can't come up with a witty title for this. Just.... brain broken. What the hell?



  • My guess is that the server does not say the file type is "image/gif" so Firefox looks up the OS's file type association for .gif files.



  •  I think the server may be fucking up the reply headers.



  • @SlyEcho said:

    My guess is that the server does not say the file type is "image/gif" so Firefox looks up the OS's file type association for .gif files.
     

    Look! We said the same thing with different words!



  • I dunno about you guys, but for me, the default opener for .gif files is not IE.  It's Windows Picture and Fax Viewer.

    Did this come up during the normal load of the page, or were you attempting to save a picture off a site?



  • @belgariontheking said:

    for me, the default opener for .gif files is not IE.  It's Windows Picture and Fax Viewer.
     

    That's a completely different issue (one that I haven't been able to get to the bottom of). The dialog shown is the one FFX presents when a requested resource cannot be handled internally, like ZIP and EXE etc. For a GIF, this is very odd, obviously.



  • Ah, good 'ol Content-Disposition: Attachment, nothing like being able to force users to not use their browser to open a file.

    On a side note, I've seen situations where .gifs open in Internet Explorer before, mainly because since Vista, Windows Picture and Fax Viewer Photo Viewer doesn't support animation.



  • I've seen that before, altough not recently. (I suppose it's been fixed in newer versions.)

    For some reason, FF doesn't recognize the MIME type and opens up the dialog. It decides that the default program should be Windows' default browser. (Set it to FireFox for additional weirdness.)



  •  That's why it's so weird though. This is the latest stable Firefox (3.6.8) on Windows 7 Ultimate (but no Picture and Fax Viewer - huh?) and the system default browser is Firefox. Yeah, the server probably sent something weird in the reply headers, but how IE got there has me completely stumped.



  • I got the same pop-up dialog with IE selected on winXP too. Here's the headers:

     

    http://c0389161.cdn.cloudfiles.rackspacecloud.com/dyn/str_strip/328212.full.gif

    GET /dyn/str_strip/328212.full.gif HTTP/1.1
    Host: c0389161.cdn.cloudfiles.rackspacecloud.com
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 ( .NET CLR 3.5.30729; .NET4.0C)
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-us,en;q=0.5
    Accept-Encoding: gzip,deflate
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 115
    Connection: keep-alive

    HTTP/1.1 200 OK
    Server: Apache
    Cache-Control: max-age=900, public
    Etag: 328b7e5c748f7392fd6d89e963cf050e
    Content-Length: 54646
    Content-Type: application/octet-stream
    Age: 2412
    Date: Tue, 10 Aug 2010 15:33:27 GMT
    Last-Modified: Wed, 21 Jul 2010 07:01:10 GMT
    Expires: Tue, 10 Aug 2010 15:08:15 GMT
    Connection: keep-alive



  •  It works if you add that location to the source of an image.

    It just fails if you link directly.



  • @dhromed said:

     I think the server may be fucking up the reply headers.

    That's TRWTF.  Firefox (or any web browser) shouldn't care what the reply headers say.  If the file extension is .gif then you treat it like a .gif file.


  • @El_Heffe said:

    @dhromed said:

     I think the server may be fucking up the reply headers.

    That's TRWTF.  Firefox (or any web browser) shouldn't care what the reply headers say.  If the file extension is .gif then you treat it like a .gif file.

    Yeah, who cares what the standard says!



  • @El_Heffe said:

    @dhromed said:

     I think the server may be fucking up the reply headers.

    That's TRWTF.  Firefox (or any web browser) shouldn't care what the reply headers say.  If the file extension is .gif then you treat it like a .gif file.
     

     Yes, all that opening of .aspx and .php files in a text editor will be terribly productive.

    TRWTF is you.



  • Does the browser pass along the headers to the opening program?



    I've had this same thing happen before and it turned into an infinite loop of "open with [browser]?" -> "OK" -> browser opens blank page -> "open with [browser]" -> ...



    I just thought this was by design to keep people's grandparents off the Interwebs.



  • @superjer said:

    Does the browser pass along the headers to the opening program?



    I've had this same thing happen before and it turned into an infinite loop of "open with [browser]?" -> "OK" -> browser opens blank page -> "open with [browser]" -> ...



    I just thought this was by design to keep people's grandparents off the Interwebs.

    You ever try to open a XPS file when Internet Explorer isn't your default browser? The only thing that can render them is IE, yet for some unfathomable reason, opening them up in IE if it's not the default browser makes IE decide to open it up in whatever browser is default regardless of whether or it can handle it. In the case of Firefox, it prompts you to open it again.... in Internet Explorer.



  • @roothorick said:

    This is the latest stable Firefox (3.6.8) on Windows 7 Ultimate (but no Picture and Fax Viewer - huh?)
     

    Out of the box (on most installs) Windows 7 associates GIF files with IE, not with Picture and Fax Viewer.

    This is probably because the new version of Picture and Fax Viewer in Windows 7 can no longer display animated GIFs (it just displays the first frame as a static image) but Internet Explorer can.



  •  @El_Heffe said:

    @dhromed said:

     I think the server may be fucking up the reply headers.

    That's TRWTF.  Firefox (or any web browser) shouldn't care what the reply headers say.  If the file extension is .gif then you treat it like a .gif file.
    The problem is that not only did the web server return the wrong type but it didn't return any file name, so the browser has no way to determine the file extension. That the URL ended in ".gif" tells you nothing about any file that may or may not have been involved in returning the content of that URL. The server could have returned a file name including a file extension, but it chose not to. (And if it were to do so, the only way it could do so is in a reply header.)


  • What I know at least, is that in web-browser program I use, if it does not understand the file-type I can just push "i" and then type in the correct MIME type, and then it will work. And, therefore, avoid this problem. Maybe there is a extension in Firefox to do something like this, too.



  • @joelkatz said:

     @El_Heffe said:

    @dhromed said:

     I think the server may be fucking up the reply headers.

    That's TRWTF.  Firefox (or any web browser) shouldn't care what the reply headers say.  If the file extension is .gif then you treat it like a .gif file.
    The problem is that not only did the web server return the wrong type but it didn't return any file name, so the browser has no way to determine the file extension. That the URL ended in ".gif" tells you nothing about any file that may or may not have been involved in returning the content of that URL. The server could have returned a file name including a file extension, but it chose not to. (And if it were to do so, the only way it could do so is in a reply header.)
     

    Huh?  There's a file name (see screenshot in OP). 



  • @El_Heffe said:

    @dhromed said:

    I think the server may be fucking up the reply headers.

    That's TRWTF.  Firefox (or any web browser) shouldn't care what the reply headers say.  If the file extension is .gif then you treat it like a .gif file.

    TRWTF is that I can't even tell whether you're just being sarcastic or you're actually being serious...



  • @joelkatz said:

     @El_Heffe said:

    @dhromed said:

     I think the server may be fucking up the reply headers.

    That's TRWTF.  Firefox (or any web browser) shouldn't care what the reply headers say.  If the file extension is .gif then you treat it like a .gif file.
    The problem is that not only did the web server return the wrong type but it didn't return any file name, so the browser has no way to determine the file extension. That the URL ended in ".gif" tells you nothing about any file that may or may not have been involved in returning the content of that URL. The server could have returned a file name including a file extension, but it chose not to. (And if it were to do so, the only way it could do so is in a reply header.)
     

    Assuming this is just plain old Firefox, the filename in the screenshot (just after "You have chosen to open") is the filename the server returns, not part of the URL.



  • @Someone You Know said:

    Out of the box (on most installs) Windows 7 associates GIF files with IE, not with Picture and Fax Viewer.

    This is probably because the new version of Picture and Fax Viewer in Windows 7 can no longer display animated GIFs (it just displays the first frame as a static image) but Internet Explorer can.



    Afaik this has always has been the case. I'm not entirely sure about Windows XP, but Vista image viewe could definitly not display animated gifs.


  • @dtech said:

    @Someone You Know said:

    Out of the box (on most installs) Windows 7 associates GIF files with IE, not with Picture and Fax Viewer.

    This is probably because the new version of Picture and Fax Viewer in Windows 7 can no longer display animated GIFs (it just displays the first frame as a static image) but Internet Explorer can.



    Afaik this has always has been the case. I'm not entirely sure about Windows XP, but Vista image viewe could definitly not display animated gifs.
     

    No, not always. XP's Picture & Fax Viewer could definitely display animated GIFs. I'm looking at an animated GIF in it right now.

    It had some issues — some animations would get to a certain frame (before the end) and just stop, and most were slower than they should be — but it was there.

    Possibly what I referred to as a change in Windows 7 was actually a change in Windows Vista that carried over to 7. I've never actually used Vista.



  • @El_Heffe said:

    @joelkatz said:

     @El_Heffe said:

    @dhromed said:

     I think the server may be fucking up the reply headers.

    That's TRWTF.  Firefox (or any web browser) shouldn't care what the reply headers say.  If the file extension is .gif then you treat it like a .gif file.
    The problem is that not only did the web server return the wrong type but it didn't return any file name, so the browser has no way to determine the file extension. That the URL ended in ".gif" tells you nothing about any file that may or may not have been involved in returning the content of that URL. The server could have returned a file name including a file extension, but it chose not to. (And if it were to do so, the only way it could do so is in a reply header.)
     

    Huh?  There's a file name (see screenshot in OP). 

    No, there's something that looks a little like a filename in the URL. [b]URLs are not filenames[/b]. If the application wants the client to popup a save/open dialog, then it can set a Content-Disposition header which includes the filename of the resource to be downloaded.

    Example:

    Content-Disposition: attachment; filename=foo.gif

    If the Content-Disposition header does not include a filename, then the client has no choice but to guess one from the URL. If you are programming Content-Disposition headers in your application this way, then your application is broken.

    Whether or not an attachment is being sent, the type of the data is determined by the media type given in the Content-Type: header. [b]Any other behavior is incorrect, regardless of what the URL looks like[/b]. TRWTF here is that the server is misconfigured, and returning a media type of "application/octet-stream" instead of "image/gif".


Log in to reply