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:
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.I think the server may be fucking up the reply headers.
-
@El_Heffe said:
@dhromed said:
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.I think the server may be fucking up the reply headers.
Yeah, who cares what the standard says!
-
@El_Heffe said:
@dhromed said:
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.I think the server may be fucking up the reply headers.
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:
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.)@dhromed said:
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.I think the server may be fucking up the reply headers.
-
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:
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.)@dhromed said:
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.I think the server may be fucking up the reply headers.
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:
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.)@dhromed said:
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.I think the server may be fucking up the reply headers.
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:
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.)@dhromed said:
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.I think the server may be fucking up the reply headers.
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".