@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".